Pipeline rewiring (--rewire-pipelines) does not register pullRequest trigger for GitHub-connected pipelines
- Dominant language
- C#
- Stars
- 478
- Forks
- 146
- Avg merge
- 7d 21h
- Merged PRs (30d)
- 2
Description
## 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:**
```json
{
"triggers": [
{
"triggerType": "continuousIntegration",
"settingsSourceType": 2,
"branchFilters": [],
"pathFilters": [],
"batchChanges": false,
"maxConcurrentBuildsPerBranch": 1
}
]
}
```
**Freshly created pipeline (working) — has both triggers:**
```json
{
"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:
```json
{
"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)
Contributor guide
Assessment
This issue has not been assessed yet.