Upload smoke test prereqs tarball#3512
Conversation
ghost
added
| done | ||
|
|
||
| echo "Generating tarball '${outputPath}' from '${tmpDir}'" | ||
| tar -cf "${outputPath}" -C $tmpDir . |
There was a problem hiding this comment.
Should --numeric-owner be specified?
There was a problem hiding this comment.
We have reached the point where this stage should be renamed IMO. It is doing much more than mirroring which hurts the readability of the pipeline. This pipeline feels more like the pre-release stage to me while the current pre-release is prep-release or init-release. That will be more so once #3497 is resolved.
If you think this is beyond the scope of your changes, and you agree, let's make sure an issue gets logged (I can do it if you don't want to).
|
This is dependent on a build job name change from dotnet/installer#16756. |
This reverts commit 037317c.
|
I reverted the Arm64 build leg name change because the change in dotnet/installer#16756 doesn't exist in the release/8.0.1xx-preview6 branch. This will allow us to these changes for the Preview 6 release. Then I'll add this back after that release. |
|
|
||
| - ${{ if eq(parameters.dotnetMajorVersion, '6.0') }}: | ||
| - name: smokeTestPreReqsArtifactNameX64 | ||
| value: Build_Tarball_x64 CentOSStream9-Offline_Artifacts |
There was a problem hiding this comment.
This is going to create a point of maintenance throughout the lifecycle of updating/retiring the distros/versions our CI runs on. What is the failure experience if this leg no longer exists? Because the main CI pipeline is defined elsewhere there is no easy way to keep these in sync.
There was a problem hiding this comment.
If it didn't exist, you'd get an error like Artifact <name> was not found for build <id>. If you run a dry run ahead of time (which I do), you'll catch this at that time.
Other options:
- Update the VMR/tarball pipeline to have an additional stage that consolidates the smoke test prereqs from the build legs and outputs them to a well-known artifact that can be consume from the release pipeline.
- Update the VMR/tarball pipeline to publish well-known artifact names specifically for x64 and arm64 from the individual build legs (no additional stage). For example,
CentOSStream9_Offline_MsftSdk_x64would publish aSmokeTestPrereqs-x64artifact andDebian11_Offline_MsftSdk_arm64would publish aSmokeTestPrereqs-arm64artifact. The release pipeline would consume these as hard-coded artifacts but with more stable names than the build legs. The key is to configure the pipeline so that one and only one build leg for each architecture is the one that publishes the prereqs artifact. That adds some maintenance burden in case of removal/addition of build legs.
From a simplicity standpoint, I consider what I've currently implemented to be the simplest. Yes, it can be broken but the churn on build legs isn't likely to be high and can be caught with dry run. And of course, the other options can cause breakage too if not maintained correctly.
Let me know your thoughts.
There was a problem hiding this comment.
I have no objections to the proposal. The CI legs change infrequently and the error message is pretty clear.
|
Holding off on merging this. It requires dotnet/installer#16855 to be merged and also to flow to release/7.0.1xx branch. |
2 participants
Updates the release pipeline to generate the smoke test prereqs tarball and upload it to blob storage for use by .NET security partners. This is implemented by combining the individual smoke test prereqs tarballs from an x64 and arm64 build leg of the source-build pipeline.
This does not implement logic to provide this tarball for public use. That's in the scope of #3015.
Fixes #3386