Provide option to point ReleasesApiConsumer at nightly builds repo

[robertbrignull]

Adds in the codeQL.cli.channel config option, as a way to point the ReleasesApiConsumer class at dsp-testing/codeql-cli-nightlies instead of at github/codeql-cli-binaries. This will be useful for the CodeQL team to test nightly builds of the CodeQL CLI.

When changing the cli channel, the intended behaviour is that it will change the installed distribution to whatever is the latest release of that channel. From reading the code I believe it should already behave this way. I can't find any checks of the semver of the currently installed extension vs the new extension, so I believe it relies on the releases always going forwards and never doing something like re-releasing an old version. Therefore there's no need for us to add any tracking of where the currently-installed extension came from.

I haven't tested this yet because I'm not in a position to do that today, but I will test it tomorrow when I'm more able.

When writing this I also spotted some ways we can make the ReleasesApiConsumer cleaner and fit in more with the style of the rest of the extension, but I'll save those changes for a separate PR.

Checklist

• CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
• Issues have been created for any UI or other user-facing changes made by this pull request.
• [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

[koesie10]

Unfortunately, this doesn't quite work. There is a check that all releases satisfy the semver version range 2.x, and nightly CLI releases are tagged like codeql-bundle-20231212, which are neither semver nor do they satisfy the semver range.

If we remove this semver check for nightly builds, then I think this should work. The update check seems to be based on the release ID, and doesn't even check that a release is newer when updating.

[robertbrignull]

There is a check that all releases satisfy the semver version range 2.x, and nightly CLI releases are tagged like codeql-bundle-20231212, which are neither semver nor do they satisfy the semver range.

Good point. I agree I think we want to just remove that check when using nightly builds. We'll just take the latest nightly release regardless of its name.

The update check seems to be based on the release ID, and doesn't even check that a release is newer when updating.

That's how I understood the code too. It uses the release ID to tell if we're on the exact same release already and therefore don't need to update. If the release IDs do not match then it always upgrades regardless of semver of the current and new release.

[robertbrignull]

I've worked around the nightly releases not having semver tags, but it wasn't pretty 😢

There are probably better ways of doing this. I'm also not hugely happy with the ReleasesApiConsumer class as a whole, but I'm resisting the urge to refacting it in this PR. I plan to do a second PR after this to make ReleasesApiConsumer a bit more modern and move it to its own file.

If this code works is it acceptable?

[robertbrignull]

I wasn't sure about whether to order based on id or createdAt, but went with id because it's a number and having to parse date strings (which might be invalid) so we can compare them is a pain.

I also wondered about passing in a comparison function instead this orderBySemver boolean, but thought maybe that could wait for followup refactoring.

[robertbrignull]

I find it odd that you can set a custom owner name and repo name separately, and it'll maybe use a custom org name with a default value for repo name. I'm not sure why someone would want that, but that's what we have. Therefore we have to check if either is set, and we can't just combine our values together into one NWO.

[koesie10]

General approach looks good to me, but I agree that we could refactor this code to be easier to understand and perhaps split up this file into a few separate files containing the different classes.

[robertbrignull]

I've pushed changes in response to @koesie10's comments and also added some tests to cover the new behaviour and hopefully fixed the existing tests.

[koesie10]

LGTM, thanks!