feat(api): migrate to api.armbian.com REST v1#129
Merged
Conversation
Replace github.armbian.com/armbian-images.json with the structured REST API. Adds ApiBoardSummary / ApiImage / ApiVendor models plus a shared HTTP client with the X-Armbian-Client header, paginated board fetch, disk cache fallback, and atomic cache writes.
Route get_boards, get_images_for_board, and get_vendors through the new API data layer, backed by AppState caches. Update the scraping helper to use api.armbian.com asset paths, and apply remaining client-side filters (stability, preinstalled application) on top of server-side filtering.
Rework prepopulate_assets and refresh_stale_assets to source board slugs and vendor logos from the new API endpoints, using the proper size segment for each asset kind. Drop the legacy images JSON cleanup path from main startup.
Update custom image board detection, download/flash operations, and system helpers to consume the REST-based BoardInfo type. Demote routine tracing logs to debug level to reduce log-file noise while keeping user-facing events at info.
Introduce VendorInfo, refresh BoardInfo/ImageInfo to match the ApiBoardSummary/ApiImage shape (support_tier, companions, display variants, format field), and update useTauri invokers plus shared utilities to the new field names.
Adapt ImageModal, BoardBadges, FlashProgress, vendor logo loading, and the flash operation hook to the new support_tier / format / companions fields exposed by the REST API. Ensures QDL detection and badge rendering stay in sync with the backend migration.
🧪 Test BuildsVersion:
ℹ️ About these builds
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This branch migrates the imager's data layer from the legacy
github.armbian.com/armbian-images.jsondump to the new structuredapi.armbian.com/api/v1REST API. Boards, images, and vendors are now served via dedicated, paginated endpoints, which lets us drop a lot of the ad-hoc parsing and grouping logic and rely on fields the API already provides (support_tier,format,companions,display_variants).On the backend, a shared HTTP client sends the
X-Armbian-Clientheader on every call, uses a short 10s timeout for metadata (keeping the long timeout only for image downloads), and hardens the integration witherror_for_status, proper URL-encoded query params, paginated board fetch with an empty-page break and a hard safety cap, plus atomic JSON cache writes with a unique tmp suffix. The disk cache remains the offline fallback and is now populated from the REST responses. Picture-cache prepopulation and background refresh also flow through the new board and vendor lists.On the frontend, the types (
BoardInfo,ImageInfo, the newVendorInfo), IPC wrappers, image modal, board badges, vendor logo loading, and the QDL/flash hook are all updated to consume the REST schema. Routine tracing logs were demoted to debug level so uploaded session logs stay readable; user-facing events (flash start/end, device add/remove, authorization, errors) remain at info.