Prevent Apple Helix stalls and skip hanging MacCatalyst test

[matouskozak]

Should help with maccatalyst timeouts

Summary

• Disable automatic ASP.NET Core development-certificate generation in Apple mobile Helix work items. This prevents dotnet first-run certificate setup from blocking before XHarness starts.
• Skip SearchValues_GetValues only on MacCatalyst CoreCLR while the runtime hang is tracked by System.Memory.Tests hangs after SearchValues_GetValues starts on MacCatalyst CoreCLR #131891. Mono and NativeAOT remain covered.

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates the Apple mobile Helix work item setup so the .NET SDK won’t attempt to generate an ASP.NET Core development HTTPS certificate during job startup (which can block execution before XHarness begins).

Changes:

• Add a Helix pre-command for Apple mobile work items to set DOTNET_GENERATE_ASPNET_CERTIFICATE=false.
• Add an in-file note explaining why the environment variable is being set.

[matouskozak]

/azp run runtime-maccatalyst

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Memory/tests/System.Memory.Tests.csproj:8

• This adds an maccatalyst/CoreCLR CI skip for System.Memory tests (IgnoreForCI), but the PR description/title only mention disabling ASP.NET dev-certificate generation for Apple Helix jobs. If this skip is still required after the new DOTNET_GENERATE_ASPNET_CERTIFICATE precommand, please document the tracking issue / rationale here (or in the PR description) so it’s clear why System.Memory is being disabled on that configuration; otherwise consider dropping the IgnoreForCI to avoid reducing coverage.

    <!-- The test app hangs during execution on MacCatalyst CoreCLR and exceeds the 75-minute XHarness timeout. -->
    <IgnoreForCI Condition="'$(TargetOS)' == 'maccatalyst' and '$(UseMonoRuntime)' != 'true' and '$(UseNativeAOTRuntime)' != 'true' and '$(EnableAppSandbox)' != 'true' and '$(RunSmokeTestsOnly)' != 'true'">true</IgnoreForCI>

[matouskozak]

/azp run runtime-maccatalyst

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[akoeplinger]

if this works we could look at passing it everywhere, most (all?) test suites shouldn't need that cert

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/libraries/System.Memory/tests/System.Memory.Tests.csproj:7

• The comment says this helps identify “any MacCatalyst CoreCLR test”, but this setting only applies to the System.Memory test project. This is misleading when skimming logs/config; please scope the comment to this project/suite.

    <!-- Log test starts and thread IDs to identify any MacCatalyst CoreCLR test that exceeds the XHarness timeout. -->

src/libraries/sendtohelix-mobile.targets:38

• DOTNET_GENERATE_ASPNET_CERTIFICATE is introduced here but doesn’t appear anywhere else in the repo. To make this maintainable (and to ensure the intended behavior doesn’t silently become a no-op), it would help to add a reference (docs/issue/source) that defines this knob and the expected values on the .NET SDK/runtime used by Helix.

    <!-- ASP.NET Core development certificate generation can block Apple Helix work items before XHarness starts. -->
    <HelixPreCommand Include="export DOTNET_GENERATE_ASPNET_CERTIFICATE=false" />

eng/testing/tests.ioslike.targets:56

• XHARNESS_LOG_THREAD_ID is only introduced here (no other references in the repo), so it’s hard to tell whether the pinned XHarness version actually consumes it. Adding a short note that these env var names are XHarness-controlled (and should stay in sync with the pinned XHarness package) would reduce future confusion if the variable is renamed/removed upstream.

    <_AppleXUnitProgressArguments Condition="'$(XUnitShowProgress)' == 'true'">--set-env=XHARNESS_LOG_TEST_START=true --set-env=XHARNESS_LOG_THREAD_ID=true</_AppleXUnitProgressArguments>

[matouskozak]

/azp run runtime-maccatalyst

Note

This CI trigger comment was posted with GitHub Copilot assistance.

[azure-pipelines]

No pipelines are associated with this pull request.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/libraries/System.Memory/tests/System.Memory.Tests.csproj:8

• The comment suggests this logging applies to any MacCatalyst CoreCLR run, but the property is additionally gated on EnableAppSandbox and RunSmokeTestsOnly. Updating the comment to reflect the actual conditions would avoid confusion when diagnosing timeouts.

    <!-- Log test starts and thread IDs to identify any MacCatalyst CoreCLR test that exceeds the XHarness timeout. -->
    <XUnitShowProgress Condition="'$(TargetOS)' == 'maccatalyst' and '$(UseMonoRuntime)' != 'true' and '$(UseNativeAOTRuntime)' != 'true' and '$(EnableAppSandbox)' != 'true' and '$(RunSmokeTestsOnly)' != 'true'">true</XUnitShowProgress>

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[matouskozak]

if this works we could look at passing it everywhere, most (all?) test suites shouldn't need that cert

It looks like it helps on mobile because we're building the test apps on helix. We can definitelly disable it everywhere, I suppose this would be somewhere in arcade? I can merge this in and see if we have less hangs on apple mobile CI to confirm it really solves the issue.

[matouskozak]

/ba-g the failures are unrelated (and helix monitor bug #17257