navidrome/release/wix/msitools.dockerfile

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

3 lines
68 B
Text
Raw Permalink Normal View History

ci: pull base images through mirror.gcr.io instead of ECR Public (#5997) 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.
2026-08-20 10:02:04 -04:00
FROM alpine
feat(build): MSI installer improvements (#3376) * 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>
2024-10-22 23:32:56 +00:00
RUN apk update && apk add jq msitools
WORKDIR /workspace