fix(ci): install yosys before the tests that need it (Closes #2302) - #2303
Merged
Conversation
The cli-tri `build` job has never passed. Not regressed -- never passed: 11 runs on master, 11 failures, and 0 successes across all 56 runs on every branch the workflow has ever run on. ubuntu-latest ships no yosys, and the install sat as a line inside the run block of the final step, which is ordered after `cargo test -p tri`. So fpga::tests::test_smoke_gate_json_synthetic_verify_lean -- which calls the real smoke_gate(), whose verdict ANDs in yosys_ok -- hit "[smoke-gate] SKIP: yosys not on PATH" on every run. A failed step aborts the job, so the install step had never actually executed once. Hoisted into its own named `install yosys` step placed before the test step. The inline copy installed yosys and nothing else, so it is removed in full rather than trimmed; the comment on the final step now says yosys arrives from the step above instead of claiming to install it. Every other step keeps its order and content. cli/tri/src/fpga.rs is untouched. Relaxing the assertion to tolerate a missing binary would have produced a green check that verified no synthesis at all -- the absence-is-not-a-value defect already closed in GH-2285 and GH-2287. The YAML was wrong, not the test. Checked that yosys was the only gap: smoke_gate() spawns no lake, python3 or nextpnr, theorem_matrix_ok is a hardcoded true, and the verify-lean phase is a pure-Rust synthetic fixture. Closes #2302
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Aug 20, 2026
Closed
Merged
gHashTag
added a commit
that referenced
this pull request
Aug 20, 2026
Third sequential cause in the cli-tri `build` job. #2303 fixed the yosys ordering; #2305 assigned dry_run_sweep_ok. With both landed the tests report 156 passed / 0 failed and the job reached a step that had never executed once in the workflow's history: ./target/debug/tri rtl check chips/phi --json Error: No such file or directory (os error 2) verdict lines: 0 chips/phi is a gitlink (mode 160000) to gHashTag/tt-trinity-phi. The job's checkout was a bare `uses: actions/checkout@v4` with no `with:` block, so submodules took its default of false and the directory was empty on the runner. The binary was never broken; it had nothing to read. The error is unattributed because top_from_info reads info.yaml with a plain `?` while its sibling declared_sources wraps the identical failure in .with_context() naming the path. submodules: true under the default GITHUB_TOKEN only works for a public submodule -- the token is scoped to this repo, and a private one would have converted a failing step into a failing checkout. All three chips/* submodules are public (phi 941 KB, euler 3,954 KB, gamma 5,365 KB, ~10.2 MB total), and none has a nested .gitmodules, so `true` is the minimal setting and `recursive` would buy nothing. No other workflow in the repo checks out submodules, so the setting comes from the constraint rather than from copied precedent. Not compiled: the authoring machine had ~230 MB free, too little to check out the repo or run cargo. Verified against the pinned gitlink f5456685c3593665153fe2765c85bb1f46ec14c2 via the GitHub contents API -- the commit is reachable in tt-trinity-phi, info.yaml is present and sets top_module "tt_um_trinity_nano", and all 49 declared source_files resolve against the 51 .v files in src/ at that exact commit. So check 1 "sources resolve" passes rather than merely emitting a FAIL line, and the remaining four come from one yosys pass already on PATH from #2303. The N<5 assertion is byte-identical and every other step is unchanged; build was not added to the required contexts. Closes #2307
gHashTag
added a commit
that referenced
this pull request
Aug 20, 2026
…ds (#2308) Third sequential cause in the cli-tri `build` job. #2303 fixed the yosys ordering; #2305 assigned dry_run_sweep_ok. With both landed the tests report 156 passed / 0 failed and the job reached a step that had never executed once in the workflow's history: ./target/debug/tri rtl check chips/phi --json Error: No such file or directory (os error 2) verdict lines: 0 chips/phi is a gitlink (mode 160000) to gHashTag/tt-trinity-phi. The job's checkout was a bare `uses: actions/checkout@v4` with no `with:` block, so submodules took its default of false and the directory was empty on the runner. The binary was never broken; it had nothing to read. The error is unattributed because top_from_info reads info.yaml with a plain `?` while its sibling declared_sources wraps the identical failure in .with_context() naming the path. submodules: true under the default GITHUB_TOKEN only works for a public submodule -- the token is scoped to this repo, and a private one would have converted a failing step into a failing checkout. All three chips/* submodules are public (phi 941 KB, euler 3,954 KB, gamma 5,365 KB, ~10.2 MB total), and none has a nested .gitmodules, so `true` is the minimal setting and `recursive` would buy nothing. No other workflow in the repo checks out submodules, so the setting comes from the constraint rather than from copied precedent. Not compiled: the authoring machine had ~230 MB free, too little to check out the repo or run cargo. Verified against the pinned gitlink f5456685c3593665153fe2765c85bb1f46ec14c2 via the GitHub contents API -- the commit is reachable in tt-trinity-phi, info.yaml is present and sets top_module "tt_um_trinity_nano", and all 49 declared source_files resolve against the 51 .v files in src/ at that exact commit. So check 1 "sources resolve" passes rather than merely emitting a FAIL line, and the remaining four come from one yosys pass already on PATH from #2303. The N<5 assertion is byte-identical and every other step is unchanged; build was not added to the required contexts. Closes #2307
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.
Closes #2302.
The
buildjob in.github/workflows/cli-tri.ymlhas never passed. Notregressed -- never passed: 11 runs on
master, 11 failures, and 0successes out of 56 runs across every branch the workflow has ever run on.
Cause
ubuntu-latestships no yosys. The workflow installs it, but as a line insidethe
runblock of the final step, which is ordered aftercargo test -p tri:fpga::tests::test_smoke_gate_json_synthetic_verify_leancalls the realsmoke_gate(), whose verdict ANDs inyosys_ok, so every run produced:A failed step aborts the job, so the install step had never once executed.
Step order
actions/checkout@v4actions/checkout@v4dtolnay/rust-toolchain@stabledtolnay/rust-toolchain@stablecargo build -p tri --all-targetscargo build -p tri --all-targetscargo test -p triinstall yosys(new)the CLI actually produces a report(installs yosys inline)cargo test -p trithe CLI actually produces a report(inline install removed)The duplicate install was removed
Checked what the inline line carried before deleting it:
sudo apt-get update -qq && sudo apt-get install -y -qq yosysinstalls yosys and nothing else, soonce hoisted it was pure duplication and is removed in full rather than trimmed.
Had it pulled a second package, that part would have stayed. The comment above
the final step now says yosys arrives from the step above rather than claiming to
install it. Every other step keeps its order and content.
The test is untouched
cli/tri/src/fpga.rsis not modified. Making the assertion tolerate a missingyosys would turn the check green while verifying no synthesis at all -- the
absence-is-not-a-value defect already closed twice, in #2285 and #2287. A gate
must not treat "I could not look" as "I looked and it was fine".
Scope check
Verified yosys was the only missing dependency, so this does not just move the
failure. Inside
smoke_gate()(cli/tri/src/fpga.rs:5946-6350) there is nolake, nopython3, nonextpnr-- yosys is the only external binary spawned.theorem_matrix_okis a hardcodedtrue, and verify-lean is a pure-Rustsynthetic fixture that writes and re-reads its own JSON. The run log agrees: the
yosys skip was the only phase reporting anything but OK.
One honest caveat
Because the job always died at the test step, the final
tri rtl checkstep hasnever run in CI. This PR exercises it for the first time. If
buildstillfails here, that step is the most likely place, and it would be a real finding
rather than a regression from this change.