CI builds were failing at random with:
buildx failed with: toomanyrequests: Rate exceeded
The 429 comes from public.ecr.aws, not Docker Hub. AWS caps unauthenticated
ECR Public pulls at 1 per second per source IP (authenticated: 10/s). The
build matrix starts 11 jobs at once and each resolves 4 base images, so
roughly 44 anonymous pulls land in a couple of seconds — from GitHub runner
IPs that are shared with every other GitHub customer.
Measured against public.ecr.aws with an anonymous token, 60 requests at
concurrency 30 returned 31x 429 in 0.48s.
The same probe against mirror.gcr.io (Google's Docker Hub pull-through
cache) returned zero errors: 750 manifest requests up to ~141 req/s, plus
120 layer blob requests at concurrency 60. Google publishes no rate limit
for it, so this is measured headroom, not a contract — but it is roughly
10x the pipeline's peak rate, and cached pulls do not count against Docker
Hub's limits either.
Authenticating to ECR Public was the alternative. It was rejected because
10 pulls/s is still under the ~44-pull burst, it needs an AWS account plus
a secret, and secrets never reach fork pull requests — so forks would keep
failing. The mirror fixes forks too.
Verified buildkit honours the mirror block by routing a build through a
local logging registry: all 6 requests (manifests and blobs) hit the mirror,
none went to Docker Hub directly. Confirmed mirror.gcr.io answers 200 for
buildkit's "?ns=docker.io" query form on all four images, for both GET and
HEAD. Confirmed buildkit falls back to Docker Hub when the mirror is
unreachable — the build still succeeds, but the resolve takes ~30s instead
of ~0.3s, so a mirror outage means slow builds, not broken ones. The
existing Docker Hub login covers that fallback on main-repo runs.
msitools.dockerfile is only used by the local `make docker-msi` target, but
is switched over too so no ECR Public reference is left behind.
* feat(build): add a make target to build a msi installer locally
* Testing wrapping the executable in cmd
* build(ci): build msis in parallel
* feat(server): add LogFile config option
* Revert "Testing wrapping the executable in cmd"
This reverts commit be29592254cb903fd4904f2f50d4d1a860795d33.
* Adding --log-file for service executable
* feat(ini): wip
* feat(ini): parse nested ini section
* fix(conf): fix fatal error messages
* Now navidrome supports INI, we can use the built-in msi ini system
and not require the VBScript to convert it into toml
* File needs to be called .ini to be parsed as an INI and correct filename
needs to be passed to the service
* fix(msi): build msi locally
* fix(msi): pipeline
* fix(msi): pipeline
* fix(msi): pipeline
* fix(msi): pipeline
* fix(msi): pipeline
* fix(msi): Makefile
* fix(msi): more clean up
* fix(log): convert LF to CRLF on Windows
* fix(msi): config filename should be case-insensitive
* fix(msi): make it a little more idiomatic
* Including the latest windows release of ffmpeg into the msi
as built by https://www.gyan.dev/ffmpeg/builds/ (linked
to on the official ffmpeg source)
* This should version independent
* Need bash expansion for the * to work
* This will run twice, once for x86 and once for x64, I'll make it cache
the executable for now as it'll be quicker
* Silencing wget
* Add ffmpeg path to the config so Navidrome knows where to find it
* refactor: download ffmpeg from our repository
* When going back from the "Are you ready to install?" it should go back to the
Settings dialogue that you just came from
* fix: comments
---------
Co-authored-by: Deluan <deluan@navidrome.org>
