Skip to content

Builds should download from the fbuild-controlled mirror bucket by default #1806

Closed

Description

@zackees

Problem

Builds do not use the fbuild-controlled download mirror (DigitalOcean Spaces, bucket fbuild, https://fbuild.sfo3.digitaloceanspaces.com) added in #1797. The mirror is opt-in via FBUILD_DOWNLOAD_MIRRORS, and no workflow, CI script or code default sets it, so every build downloads from the vendor first.

Audit (2026-10-30):

  • Registry packages are present in the bucket at the {path} key (espressif32 6.5.0 / 6.13.0, atmelsam 9.0.0, espressif8266 4.0.1, toolchain-xtensa-esp32s3 all 200).
  • ~66 GitHub archive/ / releases/download/ URLs (Arduino cores, Adafruit TinyUSB, platform-ch32v, …) map to a bare filename under {path} (e.g. 1.8.6.tar.gz), which collides across repos and is absent from the bucket.
  • Registry API lookups (fbuild-library/src/library/registry.rs) and the clang manifest (fbuild-toolchain/src/toolchain/clang.rs) bypass the mirror layer (metadata, out of scope here).

Fix

  1. Default FBUILD_DOWNLOAD_MIRRORS to https://fbuild.sfo3.digitaloceanspaces.com/{path} and default to mirror-first, so every build tries our bucket first and falls back to the vendor URL. An explicitly set env var (including empty, to opt out) overrides; FBUILD_DOWNLOAD_MIRROR_FIRST=0 restores vendor-first.
  2. Give GitHub downloads a collision-free {path}: github.com/<owner>/<repo>/<rest> so the bucket can mirror them key-for-key.
  3. Tests for both; README updated.

Uploading the GitHub archives into the bucket is a follow-up for whoever holds the Spaces credentials.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions