Skip to content

fix(ci): install yosys before the tests that need it (Closes #2302) - #2303

Merged
gHashTag merged 1 commit into
masterfrom
fix/2302-yosys-before-tests
Aug 20, 2026
Merged

fix(ci): install yosys before the tests that need it (Closes #2302)#2303
gHashTag merged 1 commit into
masterfrom
fix/2302-yosys-before-tests

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Closes #2302.

The build job in .github/workflows/cli-tri.yml has never passed. Not
regressed -- never passed: 11 runs on master, 11 failures, and 0
successes out of 56 runs
across every branch the workflow has ever run on.

Cause

ubuntu-latest ships no yosys. The workflow installs it, but as a line inside
the run block of the final step, which is ordered after cargo test -p tri:

      - name: cargo test -p tri          # needs yosys, runs first
        run: cargo test -p tri

      - name: the CLI actually produces a report
        run: |
          set -uo pipefail
          sudo apt-get update -qq && sudo apt-get install -y -qq yosys   # too late

fpga::tests::test_smoke_gate_json_synthetic_verify_lean calls the real
smoke_gate(), whose verdict ANDs in yosys_ok, so every run produced:

[smoke-gate] SKIP: yosys not on PATH
[smoke-gate] complete (passed: false)
test result: FAILED. 155 passed; 1 failed

A failed step aborts the job, so the install step had never once executed.

Step order

before after
1 actions/checkout@v4 actions/checkout@v4
2 dtolnay/rust-toolchain@stable dtolnay/rust-toolchain@stable
3 cargo build -p tri --all-targets cargo build -p tri --all-targets
4 cargo test -p tri install yosys (new)
5 the CLI actually produces a report (installs yosys inline) cargo test -p tri
6 -- the 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 yosys installs yosys and nothing else, so
once 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.rs is not modified. Making the assertion tolerate a missing
yosys 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 no
lake, no python3, no nextpnr -- yosys is the only external binary spawned.
theorem_matrix_ok is a hardcoded true, and verify-lean is a pure-Rust
synthetic 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 check step has
never run in CI. This PR exercises it for the first time. If build still
fails here, that step is the most likely place, and it would be a real finding
rather than a regression from this change.

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
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-08-20 09:08:15 UTC

Summary

Status Count
Total Open PRs 20
PRs with Failing Checks 5
PRs with All Checks Green 15
READY 7
FAILING 5
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=cbbfac87dff3 != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit a8c5803 into master Aug 20, 2026
21 of 25 checks passed
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

cli-tri build has never passed: yosys is installed after the tests that need it

1 participant