chore(release): promote develop to main — the agent-runtime image build, actually fixed - #677
Merged
Conversation
… says why The build still breaks in CI, and the reason I cannot yet name it is the defect this commit fixes: the step reports the wrong error, three commands late. CI shows `mv: can't rename '/tmp/opa': No such file or directory` and — this is the part that matters — **no output at all from curl or from node** in between, even with `-S`, which prints errors. Neither the download failing nor the `test -s` after it aborted the run. A `;` chain that should have stopped and did not turns every failure into the same misleading message. So the step is now an `&&` chain rather than `set -eu` with `;`. Any failure stops AT that command, with that command's own message. `set -x` traces each step, the pin and the URL are echoed, `test -n` refuses an empty version, and `ls -l` shows what was actually downloaded before anything is moved. This does NOT claim to fix the root cause. It cannot be reproduced here: the image builds clean locally on both arm64 and, with `--no-cache`, on linux/amd64 — the pin resolves to 1.19.0, curl fetches 60,526,763 bytes and `opa version` reports `Version: 1.19.0`. Whatever differs is in the runner, and until now the build was incapable of saying what. Now it will. Guessing at a cause I cannot observe would be the same mistake as shipping the first version with the image unverified. This makes the next CI run answer the question. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
…ts-own-failure fix(agent-runtime): the OPA step fails at the command that fails, and says why An && chain with set -x replaces set -eu with ';', which was not aborting on either the download failure or the test -s guard, so CI reported `mv: can't rename` three commands after the cause and with no curl or node output at all. This does not claim to fix the root cause — it makes the next run able to name it.
…not exist on a clean checkout
Root cause, at last, and it was never the download.
`.gitignore:47` ignores `.harness/bin/` — roughly 400 MB of platform OPA binaries —
so git tracks not one file there. A developer's machine has that directory because
they downloaded into it. **A clean checkout does not have it at all.** So
`mv /tmp/opa .harness/bin/opa` failed for want of a destination.
Two things hid this for three attempts:
* BusyBox `mv` names the SOURCE when the DESTINATION is missing —
`can't rename '/tmp/opa': No such file or directory` reads exactly like a download
that produced nothing, which is what I chased first with wget→curl.
* Every local build passed, because it used files that exist only on my disk. That is
the same class of error as the original one: verifying something adjacent to what
CI runs instead of what CI runs.
`mkdir -p .harness/bin` before the move. One line.
**Two claims of mine are corrected in the process.** The Dockerfile comment, and the
commit that introduced this step, said the build was shipping a Mach-O binary into a
Linux image. It was not: those binaries are gitignored, so on CI there was no binary
at all — which is what the original audit actually said ("absent from the alpine
image"). I overstated it, and the corrected comments now say what is true.
Verified the way it should have been from the start: in a clean `git worktree` — no
`.harness/bin/`, exactly what the runner checks out — building `--platform
linux/amd64 --no-cache`. `mkdir -p` runs, `mv` succeeds, `opa version` reports
`Version: 1.19.0`.
A note the chain earned: a transient DNS failure during one of these runs stopped the
build AT `apk add` and said so. Under the previous `;` form that would have surfaced
as the same misleading `mv` error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: aarroyo <beyondnet.peru@gmail.com>
…-gitignored fix(agent-runtime): create the OPA destination directory, which does not exist on a clean checkout .gitignore ignores .harness/bin/, so git tracks no file there and a clean checkout has no such directory — mv failed for want of a destination, not a download. BusyBox mv names the source when the destination is missing, which is what sent the previous two attempts after the download. Verified in a clean git worktree on linux/amd64.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
4 tasks
📊 Bilingual Coverage ImpactPR Changes
Repository Coverage
✅ Good: All EN changes have ES counterparts. Generated by GitHub Actions |
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
1 participant
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.
Pull Request Summary
Four commits, one file changes:
src/apps/agent-runtime-api/Dockerfile.maincannot build the agent-runtime image today. This carries the fix and, with it, the reason the previous two attempts missed.The root cause
.gitignore:47ignores.harness/bin/— roughly 400 MB of platform OPA binaries — so git tracks not one file there. A developer's machine has that directory because they downloaded into it; a clean checkout does not have it at all.mv /tmp/opa .harness/bin/opafailed for want of a destination, never a download.mkdir -p .harness/binbefore the move. One line.Why it took three tries
mvnames the source when the destination is missing.can't rename '/tmp/opa': No such file or directoryreads exactly like a download that produced nothing — which sent #672 after wget→curl. That change was still necessary: BusyBox wget genuinely does not follow the redirect.&&chain withset -xin place ofset -euwith;, which was aborting on nothing. It proved itself immediately — a transient DNS failure during verification stopped the build atapk addand said so, where the old form would have shown the same misleadingmv.Verified as CI runs it
In a clean
git worktree— no.harness/bin/, exactly what the runner checks out —--platform linux/amd64 --no-cache:A correction carried in the diff
The Dockerfile comment and the commit that introduced this step claimed the build was shipping a Mach-O binary into a Linux image. It was not: those binaries are gitignored, so on CI there was no binary at all — which is what the original audit said ("absent from the alpine image"). The comments now say what is true.
Before you submit
Signed-off-by.Linked ADRs / Issues
main, which will be closedWhat the reviewer should know
This PR's green checks will not prove the image builds.
Build & Push Services (GHCR)is gated ongithub.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/v'): it does not run on pull requests and is skipped ondevelop. The first honest signal arrives only once this merges andmainmoves — which is exactly how a broken image crossed #669, #670 and #673 with 46, 78 and 47 green checks respectively.The evidence that this works is the clean-worktree build quoted above. The evidence about the runner arrives after the merge. That ordering is the finding worth acting on: the only job that answers "does the artifact we ship actually build?" runs after every gate that could have stopped it.
🤖 Generated with Claude Code