Skip to content

Conversation

elinor-fung
Copy link
Member

@elinor-fung elinor-fung commented Apr 3, 2025

Update installer pipelines to send host tests to helix instead of running locally

  • Add a post-build step to the installer jobs to send host tests to Helix
  • Test runs are named host-<os>-<arch> @ <helix_queue>
  • Remove explicit upload of build artifacts on failure.
    • This was for test failure repro/investigation. It is now part of the helix correlation payload, so they can be downloaded that way
  • From this PR: Send to Helix step

This change only handles platforms that we were already running tests on (linux_x64, osx_x64, windown_x64, windows_x86). We would want further updates to add other platforms (for example, arm64, linux_musl).

This does remove running of Microsoft.DotNet.CoreSetup.Packaging.Tests tests in PR/CI. I don't think those are particularly useful at this point - I've haven't seen them fail and find an issue in my time here,

Test updates:

  • Copy debug CRT to output directory when building IJW test library in debug - we need this to run IJW tests on the test machine
  • Resolve /tmp symlink on macOS for test artifacts and assets path for expected path comparisons
  • Add retry for restoring test file backup

Contributes to #77800

cc @dotnet/appmodel

@ghost ghost added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Apr 3, 2025
@elinor-fung
Copy link
Member Author

/azp run runtime

Copy link

Azure Pipelines failed to run 1 pipeline(s).

@elinor-fung elinor-fung closed this Apr 3, 2025
@elinor-fung elinor-fung reopened this Apr 3, 2025
@elinor-fung elinor-fung closed this Apr 3, 2025
@elinor-fung elinor-fung reopened this Apr 3, 2025
@elinor-fung elinor-fung force-pushed the hostTests-helix branch 3 times, most recently from fb99271 to 246c9d9 Compare April 3, 2025 18:30
parameters:
DisplayNamePrefix: Send to Helix
HelixProjectPath: src/installer/tests/helixpublish.proj
HelixProjectArguments: /p:Configuration=${{ parameters.buildConfig }} /p:TargetArchitecture=${{ parameters.archType }} /p:TargetRuntimeIdentifier=${{ parameters.targetRid }} /p:TargetOS=${{ parameters.osGroup }}
Copy link
Member

Choose a reason for hiding this comment

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

Just curious, if we remove TargetRuntimeIdentifier from here, would it default to OutputRID as before?

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, I think the host tests always use OutputRID, so TargetRuntimeIdentifier is not needed/used (and this is just from using the arguments from libraries tests as reference)

Copy link
Member

Choose a reason for hiding this comment

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

On this note, I think targetRid (which gets passed to builds as p:TargetRid) shouldn't be needed in eng/pipelines/* in principle as in the code, we compute the OutputRID; except for NonexistentRID (banana.24-x64 dummy RID test leg which is failing for several months) and CentOS9 (centos.9-x64 which is a non-portable RID).

cc @jkoritzinsky

@elinor-fung elinor-fung marked this pull request as ready for review April 12, 2025 01:34
@jkoritzinsky
Copy link
Member

The packaging tests should really live in Arcade as part of testing the SharedFramework SDK.

@elinor-fung
Copy link
Member Author

Opened #115522 about moving the packaging tests.

@elinor-fung elinor-fung merged commit 2b96e8a into dotnet:main May 13, 2025
156 of 159 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jun 13, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants