| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
I think this makes sense, but I did want to have a chat with you about URLs and verifying them.
Sorry, something went wrong.
There was a problem hiding this comment.
Thank you 👍 looks good to me and regression test makes the change quite clear!
(Didn't notice Andrew had already just approved 😅)
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Suppose a user requests a specific version of CodeQL by passing a tools: https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/codeql-bundle-20230203/codeql-bundle.tar.gz input to the init Action.
Previously the Action did not take note of the fact the bundle came from dsp-testing/codeql-cli-nightlies, not github/codeql-action. Most of the time, this would mean it wouldn't find a release with the requested tag, and the bundle would be correctly cached as 0.0.0-<bundleVersion> so as to avoid a clash with a stable CodeQL release. However if a release with the same tag existed on the CodeQL Action repository, then the Action would incorrectly associate the CLI version number from that stable bundle with the other bundle, and go on to cache the bundle as <cliVersion>-<bundleVersion>. This led to bundles being cached with the wrong CLI version, for example https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/codeql-bundle-20230203/codeql-bundle.tar.gz was cached as 2.12.2, since it matched this release on the github/codeql-action repo.
To resolve this, before we try to look up the CLI version number associated with a particular bundle tag, we check that that bundle originates from github/codeql-action, either the original repository on Dotcom or a synced repository on Enterprise Server.
Merge / deployment checklist