Improve CodeQL tools download time telemetry - #4105
Open
henrymercer wants to merge 3 commits into
Open
Conversation
The streaming path reported no timings at all, so we have no data for the path that most runs take. It now reports a total duration, which is also populated on the download-then-extract path. That path additionally reports the extraction duration, which was previously computed but only logged. `downloadDurationMs` keeps its existing meaning of time spent downloading alone, so existing telemetry stays comparable. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 628ce334-991a-4578-9c1b-93d2e96bbddb
Surface `tools_extraction_duration_ms` and `tools_total_duration_ms` from both the `init` and `setup-codeql` actions. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 628ce334-991a-4578-9c1b-93d2e96bbddb
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.
Pull request overview
Adds baseline telemetry for CodeQL bundle download and extraction durations across streaming and non-streaming paths.
Changes:
- Reports total, download, and extraction durations where measurable.
- Forwards new timing fields through init status reports.
- Expands tests for streaming, fallback, and non-streaming paths.
Show a summary per file
| File | Description |
|---|---|
src/tools-download.ts |
Measures and returns bundle timing data. |
src/tools-download.test.ts |
Tests timing reports across download paths. |
src/status-report.ts |
Defines the new telemetry fields. |
src/setup-codeql.test.ts |
Updates mocked download reports. |
src/setup-codeql-action.ts |
Sends timing telemetry from setup-codeql. |
src/init-action.ts |
Sends timing telemetry from init. |
lib/entry-points.js |
Generated artifact; excluded from review. |
Review details
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Files excluded by content exclusion policy (1)
- lib/entry-points.js
- Files reviewed: 6/7 changed files
- Comments generated: 0
- Review effort level: Balanced
henrymercer
marked this pull request as ready for review
August 25, 2026 17:01
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 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.
downloadAndExtracthas 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_download_duration_mstools_extraction_duration_mstools_total_duration_mstools_total_duration_msis the field to compare across the change, being theonly 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_mskeeps its existing meaning so earlier dataremains 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_msis one where streamingfailed.
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
in what order, and no new failure modes on the download path.
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?
src/tools-download.test.tscovers both paths and thefallback from streaming to download-then-extract.
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?
appearing with plausible values is the signal that it works.
Are there any special considerations for merging or releasing this change?
before any change to how the bundle is packaged, since its purpose is to
establish a baseline.
Merge / deployment checklist