fix(ci): pin aztec-packages commit in compile-noir-contracts job - #13349
Merged
Conversation
TomAFrench
reviewed
Jul 15, 2026
TomAFrench
approved these changes
Jul 15, 2026
TomAFrench
marked this pull request as ready for review
July 15, 2026 09:01
TomAFrench
enabled auto-merge
July 15, 2026 09:01
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.
Problem
The
compile-noir-contractsjob ("Compilenoir-contractszero inliner aggressiveness") in.github/workflows/test-js-packages.ymlchecks outAztecProtocol/aztec-packageswith noref:, so it always compiles against the live tip of that repo's default branch (next) at the moment CI runs. That's a moving target: the same Noir PR can be green one hour and red the next purely becausenextadvanced, with no change on the Noir side.This surfaced on noir-lang/noir#13346, where the job failed with
Comptime variable 'seed' cannot be used in runtime codein aztec-nr'soracle_testing.nr. Buildingnargofrom bothmasterand that PR and compiling against thenextcommit CI happened to pick up (48f6b87) reproduced the failure identically — so the breakage came from an aztecnext↔ noir-beta.23 mismatch that landed onnextbetween the green baseline run and the PR run, not from the PR.Every other aztec-packages consumer in the repo already pins: the
external-repo-checksmatrix and the benchmark jobs resolvereffrom&AZ_COMMITinEXTERNAL_NOIR_LIBRARIES.yml(and.github/benchmark_projects.yml), which the weeklybump-aztec-packages-commitworkflow advances via a reviewed PR. Only this one job was left floating.Fix
Resolve the pinned commit from
EXTERNAL_NOIR_LIBRARIES.yml'sdefinefield and pass it as the checkoutref, so this job tracks the exact same commit asexternal-repo-checksand gets bumped in lockstep by the existingbump-aztec-packages-commitworkflow (which already edits that file).yqis already relied on for the same file byscripts/bump-aztec-packages-commit.shand is preinstalled on the GitHububuntu-22.04runner.After this, an aztec
nextbreakage can no longer redden unrelated Noir PRs; it only surfaces when the pin is bumped, where it's expected and reviewable.Created by claudebox · group:
slackbot