Fix assumption that all CodeQL bundle URLs contain the tag name of the bundle#1517
Conversation
|
I tried to download an untagged dev CLI instance: https://github.com/dsp-testing/aeisenberg-sarif-upload/actions/runs/4106366120/jobs/7084499130 The job failed. Here is the commit sha I am working with (private repository). dsp-testing/aeisenberg-sarif-upload@0576bc5 Note that the failure reason is a 404 during download, which is strange since the URL https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/untagged-9b0f002edc6e08260e8f/codeql-bundle-linux64.tar.gz works for me when I access it from the browser. |
|
OK, So I tried again, but this time with a publicly available CLI version that has a non-standard tag. The download worked, but it looks like the tool wasn't cached in the toolcache. I don't think that's a problem. |
aeisenberg
left a comment
There was a problem hiding this comment.
Looks good. I've convinced myself that this fix will correctly download codeqls from arbitrary github releases.
|
👍, to summarize:
|
While implementing controlled switchover, we inadvertently introduced an assumption that all CodeQL bundle URLs contain the tag name of the bundle, for example
codeql-bundle-2020230120. This is in fact not the case on GHES, where the bundle URL may be https://example.githubenterprise.com/api/v3/repos/github/codeql-action/releases/assets/1 when the CodeQL sync tool has been used to sync the CodeQL bundle to the GHES instance.This PR adds a regression test and fixes that assumption.
Merge / deployment checklist