如何在Azure DevOps中从CD发布流水线触发CI构建流水线？

Great question—while triggering a CI pipeline from a CD release isn't the most common workflow, it's totally valid for your use case where you need to commit changes to a Git repo post-deployment. Let's walk through a couple of cleaner alternatives to your current "clone repo in CD" approach:

Option 1: Use the Built-in "Azure DevOps Pipeline" Task (Simplest Approach) #

Azure DevOps has a native task that lets you trigger another pipeline directly from your CD release, no custom API calls needed. Here's how to set it up:

• Navigate to your CD release pipeline, go to the last stage (after all deployment steps are completed)
• Add a new task: search for Azure DevOps Pipeline (under the Azure DevOps category)
• Configure the task:
  • Select your Azure DevOps organization and project via a service connection (create one if you don’t have it already)
  • Pick the target CI pipeline you want to trigger (the one responsible for updating the JSON file)
  • Optional: Specify the branch you want the CI pipeline to run on (e.g., main)
• Ensure your target CI pipeline includes all necessary steps:
  • Check out the Git repo (the built-in checkout task handles authentication if your pipeline has repo access)
  • Update the JSON file as required
  • Commit and push changes with a message that includes [skip ci] (you already noted this prevents infinite loops—perfect)

This approach keeps responsibilities separated: CD handles deployment, CI handles code changes. It also avoids managing Git credentials in your CD pipeline, since the CI pipeline already has the necessary repo permissions.

Option 2: Trigger via Azure DevOps REST API (More Flexible) #

If you need extra control (like passing custom parameters to the CI pipeline), use the REST API to trigger it from your CD pipeline:

• Add an Invoke REST API task to your CD release's final stage
• Configure the task:
  • Set the URL to https://dev.azure.com/{your-org}/{your-project}/_apis/pipelines/{target-ci-pipeline-id}/runs?api-version=7.1-preview.1
  • Use PAT authentication: Create a Personal Access Token (PAT) with Build (queue) and Code (read & write) permissions, add it as a secret variable in your CD pipeline, then set the Authorization header to Bearer $(your-pat-variable)
  • Set the request method to POST and add a JSON body (example):

    {
      "resources": {
        "repositories": {
          "self": {
            "refName": "refs/heads/main"
          }
        }
      },
      "templateParameters": {
        "jsonFilePath": "/path/to/your/file.json" // pass custom params if needed
      }
    }
    

• Confirm your CI pipeline handles the JSON update, commit with [skip ci], and push.

Why This Is Better Than Your Temporary Solution #

Your current approach of cloning the repo in CD works, but it has notable downsides:

• You have to manage Git credentials in the CD pipeline, adding unnecessary security overhead
• It mixes deployment logic with code change logic, making pipelines harder to maintain long-term
• CI pipelines are purpose-built for code-related tasks, so leveraging them keeps your workflow aligned with Azure DevOps best practices

Just make sure the service principal or user running your CD pipeline has Queue builds permissions on the target CI pipeline (you can set this in the CI pipeline’s Security settings under Pipeline permissions).

内容的提问来源于stack exchange，提问作者Elnoor