Skip to content

Conversation

@nagilson
Copy link
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.

@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 on lines +4 to +7
parameters:
- name: test
type: boolean
default: true
Copy link
Member

Choose a reason for hiding this comment

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

nit: For consistency, keep list elements, - {prop}, aligned with the parent property. Thus,

Suggested change
parameters:
- name: test
type: boolean
default: true
parameters:
- name: test
type: boolean
default: true

You did this with variables: and repositories: and other stuff below. It still works if it is indented extra, but it just adds to confusion about YAML if they're all not the same.

steps:
- template: pipeline-templates/install-node.yaml@self
- template: pipeline-templates/list-file-structure.yaml@self
- bash: |
Copy link
Member

Choose a reason for hiding this comment

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

bash: is a shorthand for this task: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/bash-v3?view=azure-pipelines

Any reason this script needs to be bash on Windows? It then requires the script to run under WSL. Copilot could probably directly convert this to PowerShell pretty easily. Then, this entire job just uses PowerShell.

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.

2 participants