Observed auditing rainlanguage/rain.solmem (rainlanguage/rain.solmem#87, [A25]), but the file is this repo's and every consumer of rainix-autopublish.yaml has it.
Mechanism
A consuming repo's package-release.yaml triggers on: push: branches: [main] and calls rainix-autopublish.yaml. The repo's test workflow (rainix.yaml → rainix-sol.yaml) triggers on that same event, so the two run in parallel — there is no needs: or workflow_run relationship between them.
Inside rainix-autopublish.yaml, the only test step is Cargo test, and it is gated on inputs.crates != '' || inputs.crate != ''. The Solidity path is:
Soldeer content gate → Publish to Soldeer (forge soldeer push) → Bump Soldeer version → Tag and push
No forge test, no forge build, and no dependency on the caller's CI result. A push to main that breaks the Solidity suite still publishes.
Why it matters
Soldeer revisions are immutable: a broken revision cannot be withdrawn, only superseded by another version. For rain.solmem in particular every function is internal, so src/ is inlined into the bytecode of every consuming contract — a bad revision is copied into consumers rather than referenced.
Fix
Make the publish depend on the repo's own checks. Either gate the release workflow on the test workflow's success (workflow_run on conclusion success), or run the sol test job as a needs: prerequisite inside rainix-autopublish.yaml before the push step. The gate belongs here rather than in each consuming repo's package-release.yaml, which is a four-line caller.
Refs rainlanguage/rain.solmem#87.
Observed auditing
rainlanguage/rain.solmem(rainlanguage/rain.solmem#87,[A25]), but the file is this repo's and every consumer ofrainix-autopublish.yamlhas it.Mechanism
A consuming repo's
package-release.yamltriggerson: push: branches: [main]and callsrainix-autopublish.yaml. The repo's test workflow (rainix.yaml→rainix-sol.yaml) triggers on that same event, so the two run in parallel — there is noneeds:orworkflow_runrelationship between them.Inside
rainix-autopublish.yaml, the only test step isCargo test, and it is gated oninputs.crates != '' || inputs.crate != ''. The Solidity path is:Soldeer content gate→Publish to Soldeer(forge soldeer push) →Bump Soldeer version→Tag and pushNo
forge test, noforge build, and no dependency on the caller's CI result. A push tomainthat breaks the Solidity suite still publishes.Why it matters
Soldeer revisions are immutable: a broken revision cannot be withdrawn, only superseded by another version. For
rain.solmemin particular every function isinternal, sosrc/is inlined into the bytecode of every consuming contract — a bad revision is copied into consumers rather than referenced.Fix
Make the publish depend on the repo's own checks. Either gate the release workflow on the test workflow's success (
workflow_runon conclusionsuccess), or run the sol test job as aneeds:prerequisite insiderainix-autopublish.yamlbefore the push step. The gate belongs here rather than in each consuming repo'spackage-release.yaml, which is a four-line caller.Refs rainlanguage/rain.solmem#87.