chore: Accumulated backports to v4-next#22857
Merged
Merged
Conversation
Wires CONTRACT_ARTIFACTS_VERSION-based compat testing into the release flow. On v4 releases, runs all simple e2e tests against contract artifacts from every prior stable tag (>= v4.2.0), validating new-client/old-contracts compatibility. - Blocking for stable/RC releases, report-only for nightlies - ci-skip-compat-e2e label escape hatch for release PRs - Triggered on release tags, nightly tags, or ci-compat-e2e/ci-release-pr labels Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ld-contract-artifact-new-stack-backwards
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ld-contract-artifact-new-stack-backwards
…lver Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ld-contract-artifact-new-stack-backwards
…o jan/f-550-integrate-old-contract-artifact-new-stack-backwards
…o jan/f-550-integrate-old-contract-artifact-new-stack-backwards
## Summary
Wires `CONTRACT_ARTIFACTS_VERSION`-based backwards-compat testing into
the release flow (F-550), and restructures the release pipeline so a
compat regression actually blocks stable/RC publishing.
On v4 releases, runs all simple e2e tests (excluding prover,
block_building, and epochs) against contract artifacts from every prior
stable tag >= v4.2.0, validating that new client code still works with
old contract artifacts ("new pxe / old contracts").
## How the release pipeline is wired now
Three tiers of jobs in `.github/workflows/ci3.yml`:
1. **`ci`** — verification build. On a release tag, runs `./bootstrap.sh
ci-release` which now does `semver check && build` only (no publish).
2. **`ci-compat-e2e`** — runs the compat test matrix on a dedicated EC2
instance via `./bootstrap.sh ci-compat-e2e`. Discovers prior stable tags
from `.release-please-manifest.json`, pre-populates
`.legacy-contracts/<version>/` on the host, and runs e2e tests with
`CONTRACT_ARTIFACTS_VERSION=<ver>` set. Triggered on any `refs/tags/v*`
except `-commit.`, plus on PRs with the `ci-compat-e2e` or
`ci-release-pr` labels.
3. **`ci-release-publish`** — the actual publish (`./bootstrap.sh
ci-release-publish` → `build && release`: npm publish, Docker push,
GitHub release, aztec-up scripts, etc.). `needs: [ci, ci-compat-e2e]`
with an `if:` that publishes only when ci succeeded and either the tag
is nightly or ci-compat-e2e succeeded.
### Tag class behavior
| Tag class | ci-compat-e2e | ci-release-publish |
|----------------------------------------|---------------------|------------------------------------------|
| Stable / RC (e.g. `v4.2.1`, `-rc.1`) | Runs, blocking | Gated on
compat-e2e passing |
| Nightly (e.g. `-nightly.20260417`) | Runs, observational | Publishes
regardless (`continue-on-error: true` keeps nightly green) |
| Dev `-commit.*` (ci-release-pr flow) | Skipped on tag push; runs on PR
if label applied | Skipped (`-commit.` filter) |
## Escape hatches
- `ci-skip-compat-e2e` PR label — marks compat-e2e failures non-blocking
on release PRs.
- `ci-compat-e2e` PR label — forces the job to run on a non-release PR.
# Does this thing actually work?
When I trigger it on this PR with `ci-release-pr` the thing seems to run
correctly - `ci_compat_e2e` workflow runs and is green. This tests that
the workflow itself is well setup and that the tags get resolved
correctly (i.e. it finds the correct tag and runs the tests).
What remains is to see if this gets run on nightly release in
observation mode (I got an agreement to not block on nightlies if there
is a failure since there might be flakes) and then see on the next
stable release in strict mode (if you get red `ci_compat_e2e` job then
no release should happen).
# Future work
- Forward port this to v5 (while not needed there as the code will be
dormant don't want to diverge too much)
- Would be nice to get a notification on slack if we get failure on
nightly
# How confident am I this thing is not non-sense
I have no experience with the build and release scripts but I reviewed
the diff and it makes sense to me.
…#22862) This was just poor formatting on an error msg.
Simple addition, requested by a user. Fixes #21832.
Cherry-picked #22866 --------- Co-authored-by: AztecBot <tech@aztec-labs.com> Co-authored-by: Nicolás Venturo <nicolas.venturo@gmail.com>
The `--pxe` flag has had no handler since #17228 dropped the PXE JSON-RPC server; passing it produced "No module specified to start" and exited 1. This just drops the flag.
Collaborator
Author
|
🤖 Auto-merge enabled after 8 hours of inactivity. This PR will be merged automatically once all checks pass. |
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
7 participants
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.
BEGIN_COMMIT_OVERRIDE
feat(ci): add backwards compatibility e2e tests to CI pipeline (#22606)
feat(pxe): support nested utility function calls (#22822)
fix: malformed suggestion in OwnedStateVariable storage panic message (#22862)
feat: add --json flag to aztec profile gates (#22860)
chore: prevent inlining public init check (#22869)
END_COMMIT_OVERRIDE