docs: fix build references stale since the container-build rework - #256
Merged
Conversation
PR #219 replaced the Dockerfile's Go builder stage with a binary-selector that copies pre-built binaries from bin/, and deleted .github/workflows/docker.yml. README and docs/development.md still pointed at that workflow and documented a local `docker build` that fails without bin/ populated. Signed-off-by: Sebastian Mendel <[email protected]>
|
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Contributor
There was a problem hiding this comment.
Automated approval for maintainer PR
All automated quality gates passed. See SECURITY_CONTROLS.md for compensating controls.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #256 +/- ##
=======================================
Coverage 74.70% 74.70%
=======================================
Files 10 10
Lines 427 427
=======================================
Hits 319 319
Misses 88 88
Partials 20 20
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.



PR #219 rebuilt the container build: the Dockerfile no longer compiles Go — its
binary-selectorstage copies pre-built binaries viaCOPY bin/raybeam-linux-* /tmp/, and.github/workflows/docker.ymlwas deleted. README anddocs/development.mdstill described the old world.README.md:8 — badge "Docker Build" pointed at
actions/workflows/docker.yml, a file that no longer exists (dead badge). Now a "Release" badge pointing atrelease.yml. Re-pointed rather than removed because the container image build is a real job inrelease.yml, so a status badge for it still carries information; the existing "Latest Release" badge shows the version, not whether the last run was green. There is no dedicated container workflow to point at —.github/workflows/holdsci.ymlandrelease.yml, nocontainer.yml.docs/development.md:114 — the repo tree listed
docker.yml # Docker image builds. Nowci.yml # Lint, test, coverage; therelease.ymlcomment changed from "Binary releases" to "Binaries + container image".docs/development.md:610-618 — the "GitHub Actions Workflows" section documented a Docker Build workflow (triggers: release publish, weekly cron, master push) that is gone, and a Release entry that was wrong on all three points (trigger is a
v*tag push, not release publish; binaries cover linux 386/amd64/arm64/armv6/armv7, darwin amd64/arm64 and windows amd64, not "linux and darwin (amd64)"). Replaced by an accurate CI entry and a Release entry that also covers the container image and the SBOM/attestation assets. Facts read fromrelease.ymland thenetresearch/.githubrelease-go-app.ymlorchestrator it delegates to.docs/development.md:626 —
docker build -t raybeam:test .was documented as a local build. In a fresh checkout it fails:ERROR: failed to build: failed to solve: lstat /bin: no such file or directory(theCOPY bin/raybeam-linux-*has nothing to copy). The block now cross-compiles first.docs/development.md:632-633 (not in the original report) —
docker build --target builderand--target runnerwere documented as "test multi-stage build". Both stages were removed by #219; each fails withtarget stage "builder"/"runner" could not be found(the runtime stage is unnamed now). Dropped, and replaced with a note on which binary name each platform maps to for a multi-platform build.Every command in the new block was executed in a clean worktree, in the order documented, and all three succeed:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -o bin/raybeam-linux-amd64 ., thendocker build -t raybeam:test ., thendocker run --rm raybeam:test raybeam --version→raybeam version unknown(expected: the release pipeline injects the version via ldflags). The multi-platform mapping sentence is read off the Dockerfile'scasestatement and is not a runnable command, so it was not executed; a buildx multi-arch run was not attempted.Not touched, but worth a follow-up: the Dockerfile's own header comment (lines 3-4) says the container job "downloads them back into bin/ via
gh release download". It does not —release-go-app.yml's container job usesactions/download-artifactwithpattern: binary-linux-*.