fix(ci): repair two workflow steps that have never run - #71
Open
admercs wants to merge 2 commits into
Open
Conversation
Both are config bugs that predate any recent work, and both fail the same way every time, so their red marks have stopped carrying information. Miri asked for a component stable does not have. The job installs nightly with the miri component, then runs bare `cargo miri setup` -- and rust-toolchain.toml pins channel = "stable" for the repo, which overrides whatever the action installed. So the step ran on stable, which never ships miri, and failed in ~15s. Naming the toolchain explicitly is the same fix the HV1 jobs already carry for exactly this reason. The CLA action pinned a tag that does not exist. contributor-assistant /github-action publishes only vX.Y.Z tags; there is no v2, so the step failed to resolve on every pull request. Note the second one changes behaviour: the CLA check has been inert, and repairing it makes it enforce again, which is what the workflow was written to do. Contributors will be asked to sign. If that is not wanted now, reverting this one line is enough -- but leaving a compliance control permanently broken is the worse of the two states. Neither touches the CI workflow, which is the tracked set and is green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both failed before doing any of their work, for the same reason: hv2-api's
build script runs prost-build, which needs protoc. Every building job in
ci.yml installs it with arduino/setup-protoc; coverage.yml and bench.yml
never did.
Error: Custom { kind: NotFound, error: "Could not find `protoc`. ..." }
So Coverage was failing before measuring a single line, and Benchmarks
failed with "No benchmark result was found" -- a message that reads like a
missing benchmark and was really a missing compiler. Three jobs across the
two workflows needed the step.
This does not make either workflow green on its own: both also inherit
master's Rust 1.98 clippy breakage, which the fix in the other branch
addresses. It removes the failure that was hiding everything else.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Two config bugs, both predating recent work, both failing identically every
time — so their red marks had stopped carrying information.
Miri asked for a component stable does not have
The job installs nightly with the
miricomponent, then runs barecargo miri setup. Butrust-toolchain.tomlpinschannel = "stable"for therepo and overrides whatever the action installed, so the step ran on stable
— which never ships miri:
Failed in ~15s, every run. Naming the toolchain (
cargo +nightly miri) is thesame fix the HV1 jobs already carry, for exactly this reason.
The CLA action pinned a tag that does not exist
contributor-assistant/github-actionpublishes onlyvX.Y.Ztags — there is nov2:Pinned to
v2.6.1(latest).The CLA check has been inert — failing to resolve rather than checking
anything. Repairing it makes it enforce again, which is what the workflow was
written to do, so contributors will start being asked to sign. If that is not
wanted right now, reverting that one line is enough. I judged that leaving a
compliance control permanently broken is the worse of the two states, but it is
your call and it is deliberately isolated to a single line.
Scope
Neither change touches the
CIworkflow — the tracked 19-job set, currentlygreen.
CoverageandBenchmarksalso fail on master and are not addressedhere; they need investigation rather than a one-line fix.
🤖 Generated with Claude Code