Support linux-arm64 assets in start-proxy - #4181
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Warning
- Copilot's review of this pull request may be incomplete because some of the changed files are excluded by your Copilot content exclusion settings. See Excluding content from Copilot for details.
Copilot review overview
🟢 Approval recommended
The focused platform-selection change is consistent with existing helpers and adequately tested.
Review effort: Balanced
Findings: None
What changed in this PR
Adds Linux ARM64 asset selection to start-proxy using shared platform detection.
Changes:
- Adds platform and architecture to action state.
- Selects platform-specific proxy assets with Linux ARM64 support.
- Updates unit tests and test-state helpers.
| File | Description |
|---|---|
src/action-common.ts |
Adds runtime platform and architecture to base state. |
src/testing-utils.ts |
Populates the new state fields in tests. |
src/start-proxy.ts |
Selects proxy packages by bundle platform. |
src/start-proxy-action.ts |
Passes action state into proxy resolution. |
src/start-proxy.test.ts |
Updates and extends proxy platform tests. |
lib/entry-points.js |
Generated bundle; excluded from review. |
Files excluded by content exclusion policy (1)
- lib/entry-points.js
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
henrymercer
approved these changes
Sep 29, 2026
henrymercer
left a comment
Contributor
There was a problem hiding this comment.
This looks good. Once that linux-arm64 binary is available, consider adding a PR check that validates that the latest bundle contains start-proxy assets for each platform for which we have bundles. This could also live internally.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We recently added support for CodeQL on the
linux-arm64platform. However, we did not update thestart-proxyaction, which downloads a platform-specific binary of the authentication proxy, accordingly. This PR makes a corresponding change to thestart-actionwhich uses the newgetBundlePlatformfunction to determine the platform identifier. This effectively addslinux-arm64as an option.The remaining changes are refactors / tests.
Notes for reviewers
The current behaviour of
start-proxywhen run onlinux-arm64is to download thelinux64binary, which then fails to run because of the architecture mismatch.We don't yet have
linux-arm64binaries of the proxy available in any CodeQL release, although there is a PR ondependabot/proxyto start building those.Therefore, with this change on its own,
start-proxywill still currently fail onlinux-arm64but because it cannot download thelinux-arm64asset from the CodeQL release.I am rating this as "Low risk" because
start-proxyis already failing as-is.Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
dynamicworkflows (Default Setup, Code Quality, ...).Products:
analysis-kinds: code-scanning.analysis-kinds: code-quality.Environments:
github.comand/or GitHub Enterprise Cloud with Data Residency.How did/will you validate this change?
.test.tsfiles).pr-checks).If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
linux-arm64binaries 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