-
Notifications
You must be signed in to change notification settings - Fork 433
Bump the Action minor version number on new CodeQL minor version series #3427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Updates the CodeQL Action’s versioning scheme so each new CodeQL CLI minor series can start with a new Action minor version, enabling clean backport versioning for prior GHES-associated series.
Changes:
- Bump Action version from
4.31.12to4.32.0. - Update the
update-bundleworkflow to automatically bump the Action minor version when the bundled CodeQL CLI version isx.y.0. - Regenerate
lib/artifacts to reflect the new package version.
Reviewed changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| package.json | Updates the Action version to 4.32.0. |
| package-lock.json | Keeps lockfile version fields in sync with the new Action version. |
| lib/upload-sarif-action.js | Generated artifact updated with new package version. |
| lib/upload-sarif-action-post.js | Generated artifact updated with new package version. |
| lib/upload-lib.js | Generated artifact updated with new package version. |
| lib/start-proxy-action.js | Generated artifact updated with new package version. |
| lib/start-proxy-action-post.js | Generated artifact updated with new package version. |
| lib/setup-codeql-action.js | Generated artifact updated with new package version. |
| lib/resolve-environment-action.js | Generated artifact updated with new package version. |
| lib/init-action.js | Generated artifact updated with new package version. |
| lib/init-action-post.js | Generated artifact updated with new package version. |
| lib/autobuild-action.js | Generated artifact updated with new package version. |
| lib/analyze-action.js | Generated artifact updated with new package version. |
| lib/analyze-action-post.js | Generated artifact updated with new package version. |
| .github/workflows/update-bundle.yml | Adds automatic Action minor version bump + PR body note when starting a new CodeQL CLI minor series. |
.github/workflows/update-bundle.yml
Outdated
| pr_body="$pr_body | ||
| Since this is a new CodeQL minor version series, this PR also bumps the Action version to $action_version." |
Copilot
AI
Jan 26, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multi-line pr_body assignment includes leading indentation spaces on the second paragraph (from the YAML indentation), which will be preserved in the string and can render as a Markdown code block in the created PR body. Build the second paragraph without leading spaces (e.g., concatenate with explicit \n\n... or use a heredoc/printf that does not include YAML indentation) so the PR description renders as intended.
| pr_body="$pr_body | |
| Since this is a new CodeQL minor version series, this PR also bumps the Action version to $action_version." | |
| pr_body="$pr_body"$'\n\n'"Since this is a new CodeQL minor version series, this PR also bumps the Action version to $action_version." |
mbg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to merge. One or two things to follow-up on later.
.github/workflows/update-bundle.yml
Outdated
| run: | | ||
| cli_version=$(jq -r '.cliVersion' src/defaults.json) | ||
| # Check if this is a new minor version series (patch version is 0) | ||
| if [[ "$cli_version" =~ ^[0-9]+\.[0-9]+\.0$ ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic breaks if we ever need to skip a .0 CLI release and go straight to .1 or higher. I think ideally we'd extract the minor CLI version from src/defaults.json before the ./.github/actions/update-bundle step and then compare it to the one here. Not urgent, so feel free to do that in a follow-up PR.
.github/workflows/update-bundle.yml
Outdated
| pr_body="$pr_body | ||
| Since this is a new CodeQL minor version series, this PR also bumps the Action version to $action_version." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: This is a bit horrible. Perhaps in a follow-up, see if you can make this nicer
This deals with the case that we skip `x.y.0` and go straight to `x.y.1`.
mbg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! I think the change addresses all of my feedback.
That handles the normal case, however what happens if we want to make a backport to GHES after we've already started the minor version series?
We need to release a new version of the Action based off that Action version pinning the CodeQL bundle associated with that GHES release.
This PR ensures we can assign a sensible version number to that version, by bumping the minor version number of the Action on each new CodeQL minor version series.
Suppose the version that shipped with CLI v2.23.9 was v4.31.11. Then this change makes sure the version that ships with CLI v2.24.0 will be v4.32.0 (or later). This means we can create a GHES backport that continues to pin CLI v2.23.9 and number this v4.31.12.
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
Products:
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
We'll find out because the bundle upgrade workflow will fail or the PR will be wrong.
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist