GeezerVison

We are considering shipping trimmed CodeQL bundles containing the CLI and a single language, as an alternative to today's combined per-platform bundle. This PR establishes a baseline for how long the current bundle takes, so the effect can be measured.

downloadAndExtract has two paths. The streaming path (Zstandard on Linux, which most hosted runners take) downloads and extracts concurrently, and returned an empty status report — so the dominant path reported no timings at all. The download-then-extract path reported the download duration and only logged the extraction duration.

tools_total_duration_ms is the field to compare across the change, being the only one populated on both paths. The component fields are left unpopulated on the streaming path, where downloading and extracting overlap and cannot be told apart. tools_download_duration_ms keeps its existing meaning so earlier data remains comparable.

The total is wall-clock across the whole call, so where streaming fails it includes the failed attempt and its cleanup. Those runs stay identifiable: on Linux, a report containing tools_download_duration_ms is one where streaming failed.

Compressed bundle size is deliberately not reported. For the common case it is a function of CLI version and platform, so it is already knowable from the release assets — and the size saving is the part of this that can be predicted, whereas the durations are not.

No changelog entry, as there is no user-facing change.

Risk assessment

• Low risk: telemetry only. No change to what is downloaded, from where, or in what order, and no new failure modes on the download path.

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.
• GHES - Impacts CodeQL workflows on GitHub Enterprise Server.

How did/will you validate this change?

• Unit tests - src/tools-download.test.ts covers both paths and the fallback from streaming to download-then-extract.

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 - This change is itself a telemetry change; the new fields appearing with plausible values is the signal that it works.

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

• Special considerations - This change is only useful if it is released before any change to how the bundle is packaged, since its purpose is to establish a baseline.

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.