Symptom
The docker build fails intermittently, and when it does no image is published at all — buildx
pushes a multi-arch manifest only when every platform succeeds, so one architecture failing takes
the whole release image with it.
#18 0.326 EEXIST: File exists: failed to link package: @imogen/shared@imogen-sdk/typescript/packages/shared (link)
#18 3.221 Failed to install 1 package
#18 ERROR: process "/bin/sh -c bun install --frozen-lockfile" did not complete successfully: exit code: 1
Observed on the v0.6.0 tag: docker (linux/amd64) succeeded, docker (linux/arm64) failed, and
ghcr.io/ergofobe/imogen-server:0.6.0 and :0.6 were both 404 afterwards — while
docker-compose.yml, the documented install path, had just been pinned to 0.6. Re-running the
failed job alone succeeded and the image published, so it is a race rather than a hard defect.
The same EEXIST has also been hit locally, during a bun install in a worktree, so it is not
peculiar to CI or to arm64 — arm64 simply seems to lose the race more often.
Suspected cause
Dockerfile:
RUN rm -rf node_modules && bun install --frozen-lockfile --production
rm -rf node_modules removes only the root directory. A bun workspace install also creates
packages/*/node_modules holding links to the workspace packages, and those survive. The
production install then tries to link @imogen/shared into a path that already contains it.
That alone would predict a deterministic failure, and it is not deterministic — so there is
probably also a concurrency element in bun's linking, with one architecture losing more often.
Worth confirming before fixing rather than assuming.
Expected
The production reinstall starts from a genuinely clean tree — clearing the nested
packages/*/node_modules as well as the root — or does not need a wipe at all.
Whatever the fix, a failed platform should not silently leave the release with no image. Worth
deciding whether the tag workflow should fail loudly in a way that is noticed before someone
follows a compose file pointing at a tag that does not exist.
Affected repos
Only this one. No contract change.
Context
Found while cutting v0.6.0. The release completed only because the ghcr manifest was queried
directly and found missing — the workflow summary alone showed one green run and one red, which is
easy to read as a flake and move on from.
Symptom
The docker build fails intermittently, and when it does no image is published at all — buildx
pushes a multi-arch manifest only when every platform succeeds, so one architecture failing takes
the whole release image with it.
Observed on the v0.6.0 tag:
docker (linux/amd64)succeeded,docker (linux/arm64)failed, andghcr.io/ergofobe/imogen-server:0.6.0and:0.6were both 404 afterwards — whiledocker-compose.yml, the documented install path, had just been pinned to0.6. Re-running thefailed job alone succeeded and the image published, so it is a race rather than a hard defect.
The same
EEXISThas also been hit locally, during abun installin a worktree, so it is notpeculiar to CI or to arm64 — arm64 simply seems to lose the race more often.
Suspected cause
Dockerfile:RUN rm -rf node_modules && bun install --frozen-lockfile --productionrm -rf node_modulesremoves only the root directory. A bun workspace install also createspackages/*/node_modulesholding links to the workspace packages, and those survive. Theproduction install then tries to link
@imogen/sharedinto a path that already contains it.That alone would predict a deterministic failure, and it is not deterministic — so there is
probably also a concurrency element in bun's linking, with one architecture losing more often.
Worth confirming before fixing rather than assuming.
Expected
The production reinstall starts from a genuinely clean tree — clearing the nested
packages/*/node_modulesas well as the root — or does not need a wipe at all.Whatever the fix, a failed platform should not silently leave the release with no image. Worth
deciding whether the tag workflow should fail loudly in a way that is noticed before someone
follows a compose file pointing at a tag that does not exist.
Affected repos
Only this one. No contract change.
Context
Found while cutting v0.6.0. The release completed only because the ghcr manifest was queried
directly and found missing — the workflow summary alone showed one green run and one red, which is
easy to read as a flake and move on from.