Skip to content

Fix missing CodeQL javascript snapshot by disabling CodeQL on arm64 test legs - #6680

Draft
Vineeth Thomas Alex (vineeththomasalex) wants to merge 1 commit into
mainfrom
vithoma/codeql-javascript-snapshot
Draft

Fix missing CodeQL javascript snapshot by disabling CodeQL on arm64 test legs#6680
Vineeth Thomas Alex (vineeththomasalex) wants to merge 1 commit into
mainfrom
vithoma/codeql-javascript-snapshot

Conversation

@vineeththomasalex

Copy link
Copy Markdown
Collaborator

Fixes the S360 [SFI-PS2.1] Continuous SDL -> CodeQL.Uploading action item AB#63506192:

"A CodeQL snapshot for repository ado:microsoft/projectreunion/windowsappsdk and language javascript must be produced by the Due Date." (due 2026-08-18)

Why javascript is in scope

#6158 added tools/mcp/github-artifacts (6 .js files) - the only JavaScript in the repo. CodeQL correctly detects it:

javascript: Supported. Artifacts: code: 6, ignored: 0
Detected languages: cpp,csharp,powershell,javascript,actions

Root cause

The CodeQL service accepts one upload job per (repository, commit, language), so every job that has the CodeQL 3000 tasks auto-injected races to claim each detected language. A single nightly has 64 CodeQL task records across ~30 jobs.

On the arm64 test images the CodeQL Windows tracer cannot inject into the parent process, so codeql database init fails outright:

A fatal error occurred: Injecting Windows tracer failed [exit code: 0] with message: Could not inject into parent.
##[warning]Database failed to initialize!
|javascript | failed | Database failed to initialize! |

Init is invoked once for all detected languages as a single --db-cluster with --begin-tracing (required by cpp/csharp), so that tracer failure fails every language in the cluster - including javascript, which needs no build tracing at all. The claim is then released without a database, the real producers are told the upload is "redundant", and no snapshot lands for that commit. The Finalize task confirms it:

CodeQL Init task ended without creating database, exiting...

Because it is a race it is intermittent, which is why it went unnoticed. Nightly on main:

Build Date Languages uploaded
152534661 7/19 javascript
152731647 7/22 actions, csharp, javascript, powershell
153077460 7/26 none - all 8 javascript claimants were arm64 legs
153493099 7/30 actions, csharp, javascript, powershell
153706287 8/2 none
154333949 8/10 actions only - all 8 javascript claimants were arm64 legs

Compounding this, a scan is not re-accepted for the same commit for 24 days, and main has been pinned at ee3c5078 since 7/30 - so the misses cannot self-heal and the gap keeps widening toward the due date.

The fix

One additive variable in the shared test job template, keyed off the matrix buildPlatform:

Codeql.Enabled: $[ iif(eq(variables['buildPlatform'], 'arm64'), 'false', 'true') ]

This mirrors the ob_sdl_binskim_enabled: false precedent already in this file ("we currently don't build any code here, but only run tests") - CodeQL was simply never given the same treatment.

Scoped to arm64 only, deliberately

I first drafted this as a blanket disable for the whole template, then checked which jobs actually produce successful uploads before committing. The x64/x86 legs of this same template are the primary producers of the javascript, csharp and powershell snapshots:

CheckApiChanges                             -> javascript,powershell
PipelineTests   Server25_DC_x64fre          -> csharp,javascript,powershell
TestSamplesX64  Win11_25H2_Ent_x64fre       -> csharp,javascript,powershell
PipelineTests   Win10_Ent_LTSC_2021_x64chk  -> csharp,javascript,powershell
StaticValidationTest                        -> csharp,javascript,powershell
... (~20 more x64 legs)

The compiled-language build jobs (BuildFoundation, BuildMRT) claim cpp during their MSBuild trace; the non-compiled languages get picked up by these lighter x64 jobs. Disabling the template wholesale would have removed the main javascript producer and made compliance worse, not better. Only the arm64 legs - which can never succeed - are skipped.

Verified in WindowsAppSDK-Foundation-TestConfig.yml that every arm64 matrix leg carries buildPlatform: 'arm64' (and poolName: 'WinAppSDK-Test-Pool-Arm64'), so the key is reliable.

Validation

  • YAML parses cleanly.
  • Azure Pipelines Preview API against TransportPackage-Foundation-Nightly (OneBranch) (117346) on this branch compiles the full graph (990,245 char finalYaml) - no build queued.
  • The expanded YAML confirms the variable lands on exactly the intended jobs and nothing else: PipelineTests (x3 stages), TestSamplesX64, TestSamplesArm64 and their OneBranch post* jobs.
  • Uses iif(...) returning literal lowercase 'true'/'false' rather than a bare ne() (which renders True/False) so it matches exactly what the CodeQL 3000 task parses.

Expected result

With the arm64 legs no longer claiming and dropping languages, the x64 legs reliably win javascript again (as they did on 7/19, 7/22 and 7/30). The next nightly Finalize CodeQL log should show |javascript | database uploaded |. S360 clears after analysis plus the documented ~48h ingestion latency. Merging this also moves main off ee3c5078, which conveniently resets the 24-day same-commit block.

Notes for reviewers

  • Optional follow-up, deliberately not included: full determinism would mean pinning Codeql.Language per job (plus Codeql.BuildIdentifier for the multi-job pattern in the CodeQL FAQ) so nothing races at all. I left that out because cpp/csharp are currently compliant and I did not want to risk destabilising them in a fix targeted at javascript. Codeql.BuildIdentifier in particular changes the tracking identity on the CodeQL service side, which deserves its own change and validation.
  • The 6 .js files are dev-only MCP tooling, so removing them from the repo would also retire the requirement. Given Fix GITHUB_TOKEN leak in github-artifacts MCP helper #6578 was a real GITHUB_TOKEN leak fix in that exact code, scanning it seems the better call. Note it cannot simply be excluded via Codeql.ExcludePathPatterns - the language inventory is driven by repo content, so that yields an empty database rather than compliance.

Refs: AB#63506192

…est legs

S360 [SFI-PS2.1] Continuous SDL raised a CodeQL.Uploading action item (AB#63506192):

  "A CodeQL snapshot for repository 'ado:microsoft/projectreunion/windowsappsdk'
   and language 'javascript' must be produced by the Due Date."

JavaScript entered the repo in #6158 (tools/mcp/github-artifacts, 6 .js files) and
CodeQL correctly detects it:

  javascript: Supported. Artifacts: code: 6, ignored: 0
  Detected languages: cpp,csharp,powershell,javascript,actions

The snapshot is produced only intermittently. The CodeQL service accepts one upload
job per (repository, commit, language), so every job with the CodeQL 3000 tasks
auto-injected races to claim each language (64 CodeQL task records in one nightly).
On the arm64 test images the CodeQL Windows tracer cannot inject into the parent
process and database init fails outright:

  A fatal error occurred: Injecting Windows tracer failed: Could not inject into parent.
  ##[warning]Database failed to initialize!
  |javascript | failed | Database failed to initialize! |

Because init runs once for all detected languages as a single --db-cluster with
--begin-tracing (required by cpp/csharp), that tracer failure fails every language in
the cluster, including javascript which needs no build tracing at all. Whenever an
arm64 leg wins the race the claim is released without a database and the real
producers are told the upload is redundant, so no snapshot lands for that commit.

Observed on the Nightly (main):
  152534661  7/19  javascript uploaded
  152731647  7/22  javascript uploaded
  153077460  7/26  none - all 8 javascript claimants were arm64 legs
  153493099  7/30  javascript uploaded
  153706287  8/2   none
  154333949  8/10  actions only - all 8 javascript claimants were arm64 legs

Compounding this, a scan is not re-accepted for the same commit for 24 days, and main
has been pinned at ee3c507 since 7/30, so the misses cannot self-heal.

Fix: skip CodeQL only on the arm64 legs of the shared test job template, keyed off the
matrix buildPlatform variable. The x64/x86 legs of this same template are the primary
producers of the javascript, csharp and powershell snapshots and are deliberately left
enabled. This mirrors the ob_sdl_binskim_enabled: false precedent already in this file.

Refs: AB#63506192
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 6e524c66-57a7-4c8c-b8c1-c797a4e5b447
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

@vineeththomasalex

Copy link
Copy Markdown
Collaborator Author

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 2 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR addresses intermittent missing CodeQL javascript snapshots in Azure Pipelines by preventing arm64 test legs (where CodeQL tracing fails) from participating in CodeQL language-claim/upload races, allowing x64/x86 legs to reliably produce the javascript snapshot for each commit.

Changes:

  • Adds an arm64-scoped Codeql.Enabled override in the shared test-job template.
  • Documents the underlying CodeQL 3000 race behavior and the arm64 tracer failure mode inline for future maintainers.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants