[ci] Default deploy e2e tests to the repo next version - #96895
Merged
eps1lon merged 3 commits intoAug 7, 2026
Conversation
The `nextVersion` workflow_dispatch input in `test_e2e_deploy_release.yml` declared `default: canary`, which conflicted with the version resolution added in #84840: since the input was always truthy for dispatch runs, the `needs.setup.outputs.next-version` fallback could never apply, so bare dispatches always tested `canary`. The input no longer has a default, so the tests install the `next` version extracted from `packages/next/package.json` unless someone explicitly enters a value in the dispatch form. The input description now documents that the field accepts anything installable by npm: a dist-tag like `canary`, an exact version like `16.2.4`, or a custom https tarball URL. The unreachable `|| 'canary'` fallbacks are removed from the job expressions, the adapter upload gate, and the run name, where the final operand is now the display label `repo version`.
Contributor
Tests PassedCommit: 92be011 |
Contributor
Stats from current PR✅ No significant changes detected📊 All Metrics📖 Metrics GlossaryDev Server Metrics:
Build Metrics:
Change Thresholds:
⚡ Dev Server
📦 Dev Server (Webpack) (Legacy)📦 Dev Server (Webpack)
⚡ Production Builds
📦 Production Builds (Webpack) (Legacy)📦 Production Builds (Webpack)
📦 Bundle SizesBundle Sizes⚡ TurbopackClient Main Bundles
Server Middleware
Build DetailsBuild Manifests
Build Cache
📦 WebpackClient Main Bundles
Polyfills
Pages
Server Edge SSR
Middleware
Build DetailsBuild Manifests
Build Cache
🔄 Shared (bundler-independent)Runtimes
📎 Tarball URLCommit: 92be011 |
eps1lon
changed the title
eps1lon
changed the title
'canary' default for tested version in test_e2e_deploy_release
eps1lon
changed the title
'canary' default for tested version in test_e2e_deploy_release'canary' default for tested version in test_e2e_deploy_release
The setup job now settles which `next` version the deploy e2e tests install: it outputs the `workflow_dispatch` input when one was provided and the version checked into `packages/next/package.json` otherwise. The three deploy test jobs and the adapter results upload gate consume that output directly instead of repeating the `github.event.inputs.nextVersion || needs.setup.outputs.next-version` resolution, and the upload gate now needs the `setup` job to access it. The run name still cannot reference job outputs, so release runs continue to display the release tag; a comment now documents the assumption that the release tag matches the version checked into `packages/next/package.json`.
The setup job now prints the version it settled on in a dedicated step, so the chosen specifier is visible directly in the setup job log instead of only in the generated commands of the individual deploy test jobs.
eps1lon
marked this pull request as ready for review
August 7, 2026 12:26
This was referenced Aug 7, 2026
eps1lon
changed the title
'canary' default for tested version in test_e2e_deploy_release
lubieowoce
approved these changes
Aug 7, 2026
ztanner
reviewed
Aug 7, 2026
| NEXT_ENABLE_ADAPTER=0 \ | ||
| NEXT_EXTERNAL_TESTS_FILTERS="test/deploy-tests-manifest.json" \ | ||
| NEXT_TEST_VERSION="${{ github.event.inputs.nextVersion || needs.setup.outputs.next-version || 'canary' }}" \ | ||
| NEXT_TEST_VERSION="${{ needs.setup.outputs.next-version }}" \ |
Member
There was a problem hiding this comment.
I'm wondering if the signed tarball outputs might be silently masked by GitHub here: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs
If an output is skipped because it may contain a secret, you will see the following warning message: "Skip output {output.Key} since it may contain secret."
Member
Author
There was a problem hiding this comment.
Works.
Between steps: https://github.com/vercel/next.js/actions/runs/31196722639/job/92926623131#step:7:15
Between jobs: https://github.com/vercel/next.js/actions/runs/31196722639/job/92927035198#step:34:8
Though I didn't know about this. "may contain a secret" is quite vague. But reasonable to assume a commit might get flagged due high entropy.
Member
Author
There was a problem hiding this comment.
signed tarball outputs
What do you mean with "signed"? They just have the commit in the URL. We're not signing these.
Member
There was a problem hiding this comment.
I just couldn't remember if tarball URLs were signed or not. SGTM if they are not
Member
Author
There was a problem hiding this comment.
For vercel/next.js they're just public (because the repo is public) and for vercel/next-js-mirror they're on a route requiring authorization.
ztanner
approved these changes
Aug 7, 2026
eps1lon
deleted the
sebbie/08-07-default_deploy_e2e_tests_to_repo_version
branch
August 7, 2026 17:26
eps1lon
added a commit
that referenced
this pull request
Aug 7, 2026
10 tasks
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
3 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.
This is mostly just to remove some confusion and clean up unused default values in some places.
When you run on a backport branch or older tag, you probably never want to use
canaryand just the version at that point. Running oncanarybranch will implicitly use the latest@canaryfrom NPM.Since our setup job already checks for the version declared in the checkout, we should use that everywhere so that we only have to check a single place to be sure about what version is/will be used.
I'll backport this especially because it'll fix a bug in 15.x where we ignore the release tag.