GeezerVison

We recently added support for CodeQL on the linux-arm64 platform. However, we did not update the start-proxy action, which downloads a platform-specific binary of the authentication proxy, accordingly. This PR makes a corresponding change to the start-action which uses the new getBundlePlatform function to determine the platform identifier. This effectively adds linux-arm64 as an option.

The remaining changes are refactors / tests.

Notes for reviewers

The current behaviour of start-proxy when run on linux-arm64 is to download the linux64 binary, which then fails to run because of the architecture mismatch.

We don't yet have linux-arm64 binaries of the proxy available in any CodeQL release, although there is a PR on dependabot/proxy to start building those.

Therefore, with this change on its own, start-proxy will still currently fail on linux-arm64 but because it cannot download the linux-arm64 asset from the CodeQL release.

I am rating this as "Low risk" because start-proxy is already failing as-is.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• Managed - Impacts users with dynamic workflows (Default Setup, Code Quality, ...).

Products:

• Code Scanning - The changes impact analyses when analysis-kinds: code-scanning.
• Code Quality - The changes impact analyses when analysis-kinds: code-quality.
• Other first-party - The changes impact other first-party analyses.

Environments:

• Dotcom - Impacts CodeQL workflows on github.com and/or GitHub Enterprise Cloud with Data Residency.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - I am depending on unit test coverage (i.e. tests in .test.ts files).
• End-to-end tests - I am depending on PR checks (i.e. tests in pr-checks).

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Rollback - Change can only be disabled by rolling back the release or releasing a new version with a fix.

How will you know if something goes wrong after this change is released?

• Telemetry - I rely on existing telemetry or have made changes to the telemetry.
  • Dashboards - I will watch relevant dashboards for issues after the release. Consider whether this requires this change to be released at a particular time rather than as part of a regular release.
  • Alerts - New or existing monitors will trip if something goes wrong with this change.

Are there any special considerations for merging or releasing this change?

• Special considerations - See PR description regarding the availability of linux-arm64 binaries for the proxy. We can merge this PR anytime without those being available, since it won't make things worse (they are already failing).

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.