Fix libraries-interpreter Linux failures: Configuration case mismatch

[steveisok]

Summary

The runtime-libraries-interpreter pipeline has been 100% red across all 13 retained builds (Mar 2–30). The Linux leg fails with:

dotnet: No such file or directory

Root Cause

buildConfig: release (lowercase) flows through to SendToHelix as /p:Configuration=release, but the build step produces artifacts under PascalCase Release. On Linux's case-sensitive filesystem:

Step	NetCoreAppCurrentTestHostPath
Build (-c Release)	testhost/net11.0-linux-**R**elease-x64/
SendToHelix (/p:Configuration=release)	testhost/net11.0-linux-**r**elease-x64/

SendToHelix zips an empty directory → Helix work items can't find dotnet.

Windows/macOS are case-insensitive so they find the binary (but then timeout under InterpMode=3 — separate issue).

Fix

Change buildConfig: release → buildConfig: Release to match the convention used by other working pipelines (libraries-jitstress, libraries-gcstress-extra, runtime-nativeaot-outerloop).

Confirmed via binlog analysis

Downloaded Build.binlog and SendToHelix.binlog from build 1358001. The NetCoreAppCurrentTestHostPath property differs in casing between the two binlogs.

Note

Other pipelines (gc-longrunning, r2r, superpmi-diffs) also use lowercase buildConfig and may have the same latent bug on Linux legs.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Updates the CoreCLR libraries-interpreter pipeline configuration casing so the build artifacts and the SendToHelix step agree on Configuration on Linux (case-sensitive paths), preventing empty testhost zips and subsequent “dotnet: No such file or directory” failures.

Changes:

• Change buildConfig from release → Release in the libraries-interpreter pipeline to align with produced artifact folder casing.

[github-actions]

🤖 Copilot Code Review — PR #126377

Note

This review was generated by GitHub Copilot.

Holistic Assessment

Motivation: Justified. The libraries-interpreter pipeline has been 100% red on Linux due to a case-sensitive filesystem path mismatch between the build and SendToHelix steps. The buildConfig parameter flows through two paths with inconsistent casing treatment, causing Helix to look for test archives in the wrong directory.

Approach: Correct and minimal. Changing buildConfig from release to Release aligns the raw parameter value with the PascalCase convention used by all other working sibling pipelines that also call libraries/helix.yml (e.g., libraries-pgo, libraries-jitstress, libraries-gcstress-extra, hardware-intrinsics).

Summary: ✅ LGTM. The one-line fix correctly addresses the root cause of the Linux test failures.

---

Detailed Findings

✅ Correctness — Fix addresses the real root cause

The bug occurs because buildConfig flows through two independent paths:

1. Build step: xplat-setup.yml normalizes buildConfig → buildConfigUpper → _BuildConfig = Release (PascalCase). The build args use -c $(_BuildConfig), so artifacts are produced under artifacts/helix/tests/linux.x64.Release/.

2. SendToHelix step: eng/pipelines/libraries/helix.yml line 26 passes the raw buildConfig parameter directly:

   /p:Configuration=${{ parameters.buildConfig }}
   

   With buildConfig: release, this becomes /p:Configuration=release, and OSPlatformConfig evaluates to linux.x64.release — a different path on Linux's case-sensitive filesystem.

Changing to buildConfig: Release makes the raw value match the normalized _BuildConfig, eliminating the mismatch.

Note: Azure DevOps eq() in template expressions is case-insensitive, so buildConfigUpper resolves correctly regardless — the issue is purely about the raw parameter value reaching helix.yml.

✅ Consistency — Matches established convention

All working sibling pipelines that use the same global-build-job.yml + libraries/helix.yml pattern already use PascalCase Release:

• libraries-pgo.yml → buildConfig: Release
• libraries-jitstress-random.yml → buildConfig: Release
• libraries-jitstress2-jitstressregs.yml → buildConfig: Release
• libraries-gcstress-extra.yml → buildConfig: Release
• hardware-intrinsics.yml → buildConfig: Release

💡 Cross-cutting observation — Sibling pipeline has the same latent bug

eng/pipelines/coreclr/libraries-gcstress0x3-gcstress0xc.yml uses buildConfig: release (lowercase) with the same libraries/helix.yml post-build step pattern. It likely has the same case-mismatch issue on Linux. Its schedule is currently commented out ("too many failures to be enabled"), which may be partially due to this. Out of scope for this PR, but worth a follow-up fix.

Generated by Code Review for issue #126377 · ◷

[janvorli]

Thanks for spotting this! I've read this file multiple times trying to spot anything wrong and just haven't seen this.

[steveisok]

I'll gladly take the credit for copilot ;-)