Support requesting latest nightly with tools: nightly
#3130
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for using the latest CodeQL nightly builds by allowing users to specify tools: nightly or tools: nightly-latest in their workflow configurations. This enables easier dogfooding of the latest CodeQL features for internal testing purposes.
- Adds special handling for nightly tool inputs that fetch the latest nightly release from the nightlies repository
- Updates the tool input validation logic to recognize the new nightly keywords
- Includes necessary generated JavaScript files and updates testing infrastructure to support the new feature
Reviewed Changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/setup-codeql.ts | Core implementation of nightly tool support with new constants and getNightlyToolsUrl function |
| lib/*.js | Generated JavaScript files reflecting the TypeScript changes |
| CHANGELOG.md | Documents the new nightly tools feature |
| .github/actions/prepare-test/action.yml | Updates test preparation to handle nightly tool inputs |
src/setup-codeql.ts
Outdated
| throw new Error("Could not find latest nightly release."); | ||
| } | ||
|
|
||
| return `https://github.com/${CODEQL_NIGHTLIES_REPOSITORY_OWNER}/${CODEQL_NIGHTLIES_REPOSITORY_NAME}/releases/download/${latestRelease.tag_name}/${getCodeQLBundleName(compressionMethod)}`; |
There was a problem hiding this comment.
Would it make sense to look through the release artifacts and search for the one we want, like we do for update-job-proxy?
There was a problem hiding this comment.
We could do but using the http URL is closer to how users would specify a bundle with the tools input. Things might be less optimal if we used URLs returned by the API since we perform a few optimizations by inspecting the URL structure.
| if [[ "$VERSION" == "nightly-latest" && "$RUNNER_OS" != "Windows" ]]; then | ||
| extension="tar.zst" | ||
| else | ||
| extension="tar.gz" | ||
| fi | ||
| if [[ "$USE_ALL_PLATFORM_BUNDLE" == "true" ]]; then | ||
| artifact_name="codeql-bundle.$extension" | ||
| artifact_name="codeql-bundle.tar.gz" | ||
| elif [[ "$RUNNER_OS" == "Linux" ]]; then | ||
| artifact_name="codeql-bundle-linux64.$extension" | ||
| artifact_name="codeql-bundle-linux64.tar.gz" | ||
| elif [[ "$RUNNER_OS" == "macOS" ]]; then | ||
| artifact_name="codeql-bundle-osx64.$extension" | ||
| artifact_name="codeql-bundle-osx64.tar.gz" | ||
| elif [[ "$RUNNER_OS" == "Windows" ]]; then | ||
| artifact_name="codeql-bundle-win64.$extension" | ||
| artifact_name="codeql-bundle-win64.tar.gz" | ||
| else |
There was a problem hiding this comment.
I am not sure I know off the top of my head what's prompted this change - could you explain?
There was a problem hiding this comment.
Nightly latest lookup is now handled by the Action, so the condition would never be true. And if we're referring to a specific nightly, it might not have a zstd bundle. We originally added this to improve our test coverage of zstd bundles, but now that these are shipped as latest, we have enough test coverage. So it's not really worth refactoring this to determine whether the referenced nightly has a zstd bundle.
Yes we should, thanks! |
|
Is there any future plans to differentiate |
No plans, they're just aliases. In the future we might add support for referencing a particular nightly too via something like |
To make it easier for us to dogfood CodeQL, add special values of the tools input
tools: nightlyandtools: nightly-latestthat we can use to run the latest nightly.Risk assessment
For internal use only. Please select the risk level of this change:
Merge / deployment checklist