Switch to Arcade yaml stage-based publishing with custom steps #7725
Conversation
| @@ -38,7 +37,7 @@ | |||
| <PropertyGroup> | |||
| <!-- arcade --> | |||
| <MicrosoftDotNetBuildTasksPackagingPackageVersion>1.0.0-beta.19308.1</MicrosoftDotNetBuildTasksPackagingPackageVersion> | |||
| <MicrosoftDotNetBuildTasksFeedPackageVersion>2.2.0-beta.19308.1</MicrosoftDotNetBuildTasksFeedPackageVersion> | |||
| <MicrosoftDotNetBuildTasksFeedPackageVersion>2.2.0-beta.19410.2</MicrosoftDotNetBuildTasksFeedPackageVersion> | |||
There was a problem hiding this comment.
I filed https://github.com/dotnet/core-setup/issues/7693 to get these up to date more generally and get them auto-updating.
|
I'm aware, it's tracked at dotnet/arcade#3607. I'm not waiting on it, or planning on using that as part of this effort unless migrating to it is trivial. |
dagood
added
the
* NO MERGE *
This is possible now that signing is in a different job.
dagood
removed
the
* NO MERGE *
|
Final validation build succeeded: https://dev.azure.com/dnceng/internal/_build/results?buildId=311523&view=results. Going ahead with the merge. I'll be keeping a close eye on the next build. |
|
Publish didn't work cleanly in the official build, the build is blocked right now. Check out the |
Tracking a workaround for that here: https://github.com/dotnet/core-eng/issues/7448 |
…et/core-setup#7725) * Switch to stage-based publishing with custom steps * Workaround: allow known symbol publisher warnings Use Arcade-supported symbol publish workaround * Workaround: run gather drop dry to avoid flakiness * Use hosted pool for custom publish Commit migrated from dotnet/core-setup@002bc9e
For https://github.com/dotnet/core-setup/issues/7118.
This PR splits the current publish step into three parts:
The custom publishing is configured based on channel, so it hooks in nicely with the Arcade way of specifying when a certain type of publishing should happen. By default, the custom steps aren't run. When a new channel is introduced, the configuration must be updated if custom publish should happen for it. (I was concerned earlier about how this would attach, I think this is actually pretty ideal.)
Workarounds:
-warnAsError:$falseis a workaround for [post-build] Allow passing additional parameters to sdk-task.ps1 invocation in the post-build yaml template arcade#3666.It's a bit of a time bomb (modifications toEdit: I've replaced this workaround with a manual integration of Make post-build.yml accept parameters to sdk-task.ps1 arcade#3676, so this workaround is fine to merge.eng/commonare overwritten by the next Maestro++ update), so I don't currently intend to merge this PR with it still there.--dry-runtodarc gather-droptest to (try to) avoid flakiness observed in test builds. See Change gather-drop post build script to do a dry-run arcade#3675.Example build: https://dev.azure.com/dnceng/internal/_build/results?buildId=308903&view=results. (Enabling the stages view preview feature recommended to see the flow. I find myself turning it off and on very frequently to deal with its issues.)
@riarenas @JohnTortugo @mmitche @wtgodbe