fix(ci): worker docker-publish — drop local replace + bump api pin via goproxy#5
Merged
Merged
Conversation
…a goproxy The original workflow staged the api repo under `worker/.deps/api/` and rewrote the local replace path. That worked at the OS level but the Dockerfile runs `go mod download` BEFORE `COPY . .` (for build- cache layering), so `.deps/api/` didn't yet exist in the layer where `go mod download` resolved the replace. Result: every push to main failed at layer 4 with: go: github.com/secrets-bridge/api@v0.0.0-... (replaced by ./.deps/api): reading .deps/api/go.mod: open /src/.deps/api/go.mod: no such file or directory Cleaner fix: drop the local replace AND bump the api pin to api/main's HEAD before docker build. goproxy then serves the pseudo-version matching the current api source, and the Dockerfile's existing `COPY go.mod go.sum ./` + `RUN go mod download` resolves cleanly via the normal module path with no in-context staging needed. Also bumped: - api pseudo-version 257ebd2 (pre-#41) → bd05303 (current main). The signature change `keymgmt.FromEnv(ctx)` → `(ctx, env)` from api#41 needs the new api source; the old pin couldn't compile worker. Workflow changes: - Removed the api side-by-side checkout step - Removed the `.deps/api/` move + sed rewrite step - Added a `setup-go@v5` step + `go mod edit -dropreplace` + `go get github.com/secrets-bridge/api@main` + `go mod tidy` - Reverted docker build context to `.` (was `./worker`) When the api module gets a real semver tag, swap `@main` for `@vX.Y.Z` and pin in go.mod permanently. Verified locally: `go mod tidy && go build ./...` resolves github.com/secrets-bridge/api to v0.0.0-20260529211927-bd05303fcab4 and compiles clean (the keymgmt.FromEnv two-arg signature matches).
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
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.
Root cause
worker#4's
docker-publish.ymlstaged the api repo underworker/.deps/api/and rewrote the local replace path. That worked at the OS level but the Dockerfile runsgo mod downloadbeforeCOPY . .(for build-cache layering), so.deps/api/didn't yet exist in the layer where the replace had to resolve. Every push to main failed at layer 4 with:The fix
Drop the local replace AND bump the api pin to api/main's HEAD before docker build. goproxy then serves a pseudo-version matching the current api source, and the Dockerfile's existing
COPY go.mod go.sum ./+RUN go mod downloadresolves cleanly via the normal module path with no in-context staging needed.Workflow changes
mv api-source worker/.deps/apised -i ... go.mod(rewrite replace path)actions/setup-go@v5go mod edit -dropreplacego get github.com/secrets-bridge/api@maingo mod tidy./worker.Pinned version bump
The pseudo-version pin in
go.modjumped from:v0.0.0-20260529005625-257ebd2ff86b(pre-#41) →v0.0.0-20260529211927-bd05303fcab4(current api/main HEAD)This was necessary anyway: api#41 changed
keymgmt.FromEnv(ctx)→(ctx, env), and the old pin couldn't compile worker#4's fix that already passescfg.Envthrough.Verified locally
Follow-up (post-v0.1.0)
When the api module gets a real semver tag, swap
@mainfor@vX.Y.Zin the workflow AND pin ingo.modpermanently. The dynamic@mainlookup is acceptable for the rolling:devchannel; semver-tagged builds should be reproducible.