Pipeline rewiring (--rewire-pipelines) does not register pullRequest trigger for GitHub-connected pipelines

[johnynfulleffect]

Summary

When using gh ado2gh with --rewire-pipelines, pipelines are successfully rewired from an Azure DevOps repo source to a GitHub repo source. However, the pullRequest trigger type is not registered on the pipeline definition, even when the YAML file contains a valid pr: block.

This means -pr pipelines (PR validation builds) will not fire on GitHub pull requests after migration.

Steps to Reproduce

1. Have an Azure DevOps project with YAML pipelines that have both trigger: and pr: blocks
2. Run gh ado2gh generate-script with --rewire-pipelines
3. Execute the generated migration script
4. After migration completes, open a pull request on the GitHub repository
5. Observe that -pr pipelines do not trigger

Expected Behavior

After --rewire-pipelines completes, pipelines with a pr: block in their YAML should have the pullRequest trigger type registered in their Azure DevOps pipeline definition. PRs on the GitHub repository should trigger the pipeline.

Actual Behavior

Only the continuousIntegration trigger type is registered on the pipeline definition. The pullRequest trigger type is missing. Azure DevOps does not fire the pipeline on GitHub PRs.

Root Cause

When --rewire-pipelines changes a pipeline's repository source from ADO to GitHub, Azure DevOps re-reads the YAML trigger: block and registers a continuousIntegration trigger. However, it does not re-read the pr: block to register a pullRequest trigger.

Pipelines created fresh (via az pipelines create or the Azure DevOps UI) after the repo is already pointed at GitHub correctly get both trigger types registered. The issue only affects pipelines that were rewired from an ADO repo source to GitHub.

Verification

Using the Azure DevOps Build Definitions REST API (GET _apis/build/definitions/{id}), comparing a rewired pipeline vs. a freshly created one shows the difference clearly:

Rewired pipeline (broken) — missing pullRequest trigger:

{
  "triggers": [
    {
      "triggerType": "continuousIntegration",
      "settingsSourceType": 2,
      "branchFilters": [],
      "pathFilters": [],
      "batchChanges": false,
      "maxConcurrentBuildsPerBranch": 1
    }
  ]
}

Freshly created pipeline (working) — has both triggers:

{
  "triggers": [
    {
      "triggerType": "continuousIntegration",
      "settingsSourceType": 2,
      "branchFilters": [],
      "pathFilters": [],
      "batchChanges": false,
      "maxConcurrentBuildsPerBranch": 1
    },
    {
      "triggerType": "pullRequest",
      "settingsSourceType": 2,
      "branchFilters": [],
      "pathFilters": [],
      "forks": {
        "allowFullAccessToken": false,
        "allowSecrets": true,
        "enabled": true
      }
    }
  ]
}

Both pipelines point to the same GitHub repository and reference the same YAML file that contains a valid pr: block. The only difference is how the pipeline was created: rewired vs. freshly created.

Impact

Every -pr pipeline rewired via --rewire-pipelines is silently broken for PR validation. Users don't discover this until they open a pull request and notice the pipeline doesn't run. For organizations migrating many repositories, this requires manual intervention on every affected pipeline.

Workaround

After migration, use the Azure DevOps Build Definitions REST API to add the pullRequest trigger to each affected pipeline definition:

1. GET the full pipeline definition:

   GET https://dev.azure.com/{org}/{project}/_apis/build/definitions/{definitionId}?api-version=7.1-preview.7
   

2. Append a pullRequest trigger to the triggers array:

   {
     "branchFilters": [],
     "forks": {
       "allowFullAccessToken": false,
       "allowSecrets": true,
       "enabled": true
     },
     "isCommentRequiredForPullRequest": false,
     "pathFilters": [],
     "settingsSourceType": 2,
     "triggerType": "pullRequest"
   }

   settingsSourceType: 2 means "use the YAML file definition" — Azure DevOps will read branch/path filters from the pr: block in the YAML file.

3. PUT the updated definition back:

   PUT https://dev.azure.com/{org}/{project}/_apis/build/definitions/{definitionId}?api-version=7.1-preview.7
   

This can be scripted to fix all affected pipelines in bulk.

Suggested Fix

During --rewire-pipelines, after updating the pipeline's repository source to GitHub, the tool should also:

1. Check if the referenced YAML file contains a pr: block (or assume PR triggers should be registered for any -pr pipeline)
2. Ensure a pullRequest trigger with settingsSourceType: 2 is present in the pipeline definition's triggers array via the Build Definitions API

This would make --rewire-pipelines produce fully functional pipelines that respond to both CI pushes and PR events on the GitHub repository.

Environment

• gh-ado2gh version: latest (as of February 2026)
• Azure DevOps: hosted (dev.azure.com)
• Pipeline type: YAML multi-stage pipelines with pr: blocks
• Repository type after rewire: GitHub (via GitHub service connection)