github / github/gh-gei

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

Open
#1,565 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.