fix(agent-runtime): the OPA step fails at the command that fails, and says why - #675
Merged
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>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
📊 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
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
The agent-runtime image build still fails in CI after #672, and the reason I cannot name the cause is the defect this PR fixes: the step reports the wrong error, three commands late.
CI shows:
Between those two lines there is no output from
curland none fromnode— not even an error, despite-S, which exists to print them. Neither the download failing nor thetest -sguard after it aborted the run. A;chain that should have stopped and did not turns every possible failure into the same misleading message.What changes
The step is an
&&chain instead ofset -euwith;, so any failure stops at that command, with that command's own message. Plusset -xto trace, the resolved pin and URL echoed,test -nto refuse an empty version, andls -lto show what was actually downloaded before anything is moved.What this does NOT claim
It does not claim to fix the root cause. It cannot be reproduced here — the image builds clean locally on arm64 and, with
--no-cache, onlinux/amd64:Whatever differs lives in the runner, and until now the build was incapable of saying what. Guessing at a cause I cannot observe would repeat the mistake that started this: shipping the first version while stating the image was unverified. This makes the next CI run answer the question instead.
Before you submit
Signed-off-by.Linked ADRs / Issues
wgetwithcurland was necessary but not sufficientWhat the reviewer should know
Build & Push Services (GHCR)still does not gate a pull request here, so this PR's own green checks will not prove the image builds — the same gap recorded in #672 and #673. The evidence that this step works is the local--no-cachelinux/amd64build quoted above; the evidence about the runner will arrive on the next push to a branch that job watches.🤖 Generated with Claude Code