Skip .NET SDK first-run experience in Helix work items#66916
Merged
Conversation
The .NET SDK first-run experience (welcome message, HTTPS dev cert generation, NuGet cache population) hangs on some macOS Helix machines during cert installation, taking >2 minutes and getting killed by the HelixTestRunner timeout (exit code 130). Setting DOTNET_NOLOGO and DOTNET_SKIP_FIRST_TIME_EXPERIENCE bypasses this entirely. The dev cert and NuGet cache are not needed for test execution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Hey @dotnet/aspnet-build, looks like this PR is something you want to take a look at. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the Helix test runner’s process environment to avoid .NET SDK first-run initialization during Helix work item execution, addressing macOS Helix hangs during HTTPS dev cert installation that lead to timeouts and CI failures.
Changes:
- Set
DOTNET_NOLOGO=1to suppress the .NET CLI welcome/banner output. - Set
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1to skip .NET SDK first-run behaviors (including dev cert generation) for alldotnetinvocations made by the HelixTestRunner.
DOTNET_SKIP_FIRST_TIME_EXPERIENCE is deprecated and no longer honored in .NET 8+. The actual hang is in HTTPS dev cert generation, so set DOTNET_GENERATE_ASPNET_CERTIFICATE=false to skip it specifically. Also add DOTNET_NOLOGO and DOTNET_GENERATE_ASPNET_CERTIFICATE to runtests.sh and runtests.cmd alongside the existing (deprecated) DOTNET_SKIP_FIRST_TIME_EXPERIENCE, covering both the outer dotnet invocation and the inner HelixTestRunner child processes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Youssef1313
reviewed
May 29, 2026
| // DOTNET_SKIP_FIRST_TIME_EXPERIENCE is deprecated and no longer honored | ||
| // in .NET 8+. The replacement is individual controls: | ||
| // - DOTNET_NOLOGO: suppresses the welcome banner | ||
| // - DOTNET_GENERATE_ASPNET_CERTIFICATE: skips dev cert generation (the hang) |
Youssef1313
approved these changes
May 29, 2026
Youssef1313
left a comment
Member
There was a problem hiding this comment.
Approving. Let's ensure we have some tracking issue to revert once the root cause is fixed.
Member
Author
Youssef1313
added a commit
that referenced
this pull request
Jun 17, 2026
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.
Root cause
The
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1variable set inruntests.sh/runtests.cmdis deprecated and no longer honored in .NET 8+. This means the .NET SDK first-run experience (including HTTPS dev cert generation) runs on every Helix work item.On macOS Helix machines, the dev cert generation hangs for >2 minutes, exceeding the HelixTestRunner's 2-minute timeout and killing the
dotnetprocess (exit code 130). From the logs:Passing machine (dci-mac-build-365): first-run takes 64 seconds — barely fits
Failing machine (dci-mac-build-322): first-run hangs >2 minutes → killed
This is the root cause of the widespread macOS CI failures (
osx.15.amd64.openqueue) that have been blocking PRs for over a week. Runningdotnet tool installmanually on the machines works fine because the first-run has already completed from that interactive session.Fix
Replace the deprecated variable with the current equivalents:
DOTNET_GENERATE_ASPNET_CERTIFICATE=false— skips the dev cert generation (the actual hang)DOTNET_NOLOGO=1— suppresses the welcome bannerSet in three places to cover all code paths:
runtests.sh/runtests.cmd— covers the outerdotnet HelixTestRunner.dllinvocationTestRunner.cs— covers child process invocations (dotnet tool install,dotnet nuget, etc.)