Report release version the proxy is taken from in start-proxy telemetry

[mbg]

Extends start-proxy's success telemetry with the version of the release that the proxy binary came from.

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:

• Advanced setup - Impacts users who have custom CodeQL workflows.
• 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.

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?

• No special considerations - This change can be merged at any time.

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.

[Copilot]

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.

🟡 Changes recommended

The primary telemetry payload lacks direct unit-test coverage for its field name and nesting.

1 open finding

• Add unit test verifying proxy version telemetry payload · New

What changed in this PR

Adds the originating proxy release version to successful start-proxy telemetry.

Changes:

• Returns both the proxy path and version.
• Adds start_proxy.proxy_version to telemetry.
• Extracts proxy status reporting and updates tests.

File	Description
src/​start-proxy/​status-report.ts	Defines proxy telemetry and reporting.
src/​start-proxy/​status-report.test.ts	Relocates failure-report tests.
src/​start-proxy.ts	Returns proxy path and version.
src/​start-proxy.test.ts	Verifies resolved proxy versions.
src/​start-proxy-action.ts	Sends the version in success telemetry.
lib/​entry-points.js	Generated bundle; content excluded from review.

Files excluded by content exclusion policy (1)

• lib/entry-points.js

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[henrymercer]

Would calledOnceWithExactly work here?

[mbg]

Yeah, but I don't like the sinon assertions because they only return true/false and so if the assertion fails we don't know why. The t.like will print a nice diff if the assertion fails.

[henrymercer]

I think if we use sinon.assert.calledOnceWithExactly instead of sendStatusReport.calledOnceWithExactly we'll get a good error message if the assertion fails. It's non-blocking, though.