Fix computation of fallback version number #1510
Merged
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 PR addresses a bug where we would compute a fallback version number like
0.0.0-codeql-bundle-20230105
rather than one like0.0.0-20230105
. This happened because we used the tag name0.0.0-codeql-bundle-20230105
rather than the bundle version20230105
to compute the fallback version number.This fallback version number is crucial at the moment, because the controlled switchover changes haven't yet rolled out to the GitHub-hosted runner images, and therefore at the moment, the GitHub-hosted runner images version the CodeQL tools as
0.0.0-20230105
rather than2.0.0-20230105
(or2.0.0
). So if we get the fallback version number wrong, we end up having to download the bundle from the GitHub Release in most workflows.The fix is pretty simple — I've split out the tag -> bundle version logic from
getBundleVersionFromUrl
into a new functiongetBundleVersionFromTagName
and called this ingetCodeQLSource
when we compute the fallback version. Another approach would have been to callgetBundleVersionFromUrl(`/${tagName}/`)
but that's a little hacky.I think part of the reason why this bug happened is that some of our unit tests do too much stuff. So I've rewritten the ones that test lookup to mock the toolcache, rather than using our own logic to install things into the toolcache. This allows us to test fallback versions like
0.0.0-20230105
more easily and readably by separating out concerns. I've removed one of the cases where the bundle is not cached because this is already tested in the "downloads and caches explicitly requested bundles that aren't in the toolcache" test.Merge / deployment checklist