Azure Pipelines YAML pipelines can have pipeline resource triggers (for triggering a pipeline when another YAML pipeline completes), and ‘Classic’ build pipelines have build completion triggers to do the same. ‘Classic’ Release pipelines have release triggers, which trigger every time a new build artifact is available.

But what if you’ve got a mix of ‘classic’ release and YAML pipelines? Can you trigger a YAML pipeline from a ‘classic’ release pipeline? There’s nothing built in to do this, but we can make it happen via the Azure DevOps APIs.

  1. In the Azure DevOps UI, under Pipelines, navigate to the YAML pipeline that you want to trigger.
  2. Make note of the definitionId in the URL. You’ll need this for the PIPELINE_ID value later.
  3. Click on the ‘…’ button in the top right and select Manage Security
  4. Select the <Project Name> Build Service (<Org Name>) user, and ensure Queue builds option is set to Allow.

    Note: You can also set this for all pipelines, rather than for an individual pipeline.

    Set permissions for a pipeline

  5. In the release pipeline, select the Agent Job, and ensure the Allow scripts to access the OAuth token option is checked (this will allow access to System.AccessToken)

    Set OAuth token

  6. Add a script task (I’m using the Bash Task, but you could equally use PowerShell though you’d need to adjust the script slightly)
  7. Add the following inline script:

     echo $url
     curl -s --request POST \
     -u ":$(System.AccessToken)" \
     --header "Content-Type: application/json" \
     --data '{
       "resources": {
           "repositories": {
               "self": {
                   "refName": "refs/heads/main"
     }' \

  8. If you now create a new release, once that completes you should see the YAML pipeline build queued to run. Notice that the summary indicates the build was triggered manually by the service account.

    YAML pipeline build running

Things to note:

  • Update the value assigned to PIPELINE_ID with the value you noted from the definitionId earlier.
  • If the repo uses a default branch other than main then you’ll need to modify that too.
  • The script assumes you’re triggering in the same project. If you need to trigger a pipeline in a different project you’ll need to replace $(SYSTEM.TEAMPROJECTID) with the project name, or more preferably the project id (GUID) for that project.
  • Failing to set permission to allow queuing builds won’t result in an error, but it will just mean builds aren’t queued. If builds aren’t being queued, double-check that you have enabled this on the correct pipeline, or it is enabled for all pipelines.

Credits: The curl invocation was inspired by the example at