Skip to content

Utilize a separate pipeline for release tasks#2515

Merged
nagilson merged 34 commits intodotnet:mainfrom
nagilson:nagilson-separate-pipeline-for-pub
Jan 9, 2026
Merged

Utilize a separate pipeline for release tasks#2515
nagilson merged 34 commits intodotnet:mainfrom
nagilson:nagilson-separate-pipeline-for-pub

Conversation

@nagilson
Copy link
Copy Markdown
Member

@nagilson nagilson commented Dec 4, 2025

Succeeds #2411

To migrate to a standardized deployment approach, we'd like to move away from the legacy Azure DevOps release mechanisms. The best way I've seen to do that is to have a separate release pipeline which handles only release activities - the release pipeline must be quite restricted which causes issues even trying to run our security scanners and compliance tools such as SBOM, so trying to create a deployment off our existing pipeline served challenging.

This approach is based off of the vscode-csharp release pipeline. https://github.com/dotnet/vscode-csharp/blob/main/azure-pipelines/release.yml

An example run is here: https://dev.azure.com/dnceng/internal/_build/results?buildId=2858298&view=results

Other updates to make this work:

  • Signing is not done on non-CI workflows by default, so we don't run into failures trying to pack when I run test pipeline runs in internal
  • We print the pipeline workspace since it's the standard approach for staging deployment artifacts
  • We pass the artifacts and package lock files to enable npm ci install of vsce. This is because we are blocked from installing updates in a ci machine so it would fail anytime a package sub dependency got an update (which happens nearly daily)
  • updates get version logic and other logic to work in a new deployment scenario
  • verifies PAT token
  • removes custom SBOM logic as SBOM no longer fails as it used to

Thank you to @/joerobich who was very helpful in explaining the vscode-csharp-release structure.

Comment thread release.yml Outdated
@nagilson nagilson marked this pull request as ready for review December 10, 2025 17:50
@nagilson nagilson requested a review from a team December 10, 2025 17:55
Comment thread release.yml Outdated
Comment thread release.yml Outdated
Comment thread release.yml
I believe we would fail when trying to expand .version out, but this is a cleaner approach.

I've also adjusted the call to vsce to expand arguments properly and suppressed a linter issue that surfaced when pinning the linter version - in which the linter is not quite aware that we are running a Promise<R> returning function
See comment 'await must be used to make the linter allow f to be async, which it must be' above, which elaborates on why the lint rule does not apply to this unusual context of passing an async function object
@nagilson nagilson requested a review from MiYanni January 8, 2026 23:53
@nagilson nagilson merged commit f288733 into dotnet:main Jan 9, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants