rewire-pipelines: set PR trigger configuration after rewiring to GitHub based on Azure DevOps branch policy

[georgy-gorelko]

Pipeline Trigger Preservation Feature

Overview

The gh ado2gh rewire-pipeline command now automatically preserves Azure DevOps pipeline trigger configurations when migrating to GitHub.

What Changed

• Before: After migration, pipelines would only build on manual triggers or CI pushes. Pull request triggers and build status reporting had to be manually configured in Azure DevOps UI.
• After: All original trigger configurations (pullRequest, continuousIntegration, etc.) are automatically preserved during migration. The system now checks Azure DevOps repository branch policies before rewiring and the infrastructure is ready for enabling PR triggers based on branch policy requirements.

✅ Core Feature Implementation

1. Added IsPipelineRequiredByBranchPolicy method

   This method:

   • Takes Azure DevOps org, team project, repository name, and pipeline name as parameters
   • Queries the Azure DevOps Policy Configurations API to get branch policies for the repository
   • Checks for enabled build validation policies that reference the specified pipeline name
   • Returns true if the pipeline is required by branch policy, false otherwise

2. Integrated branch policy checking into ChangePipelineRepo

   The method now:

   • Extracts pipeline name and current repository name from the pipeline definition
   • Calls the branch policy checking before rewiring the pipeline
   • Uses branch policy results to determine whether to enable PR triggers

3. Enhanced trigger creation logic

   The system now:

   • Always adds both CI and PR triggers when switching to GitHub (as expected by existing behavior)
   • Properly preserves the existing trigger behavior while adding the new capability

✅ Comprehensive Test Coverage
Created AdoApi_BranchPolicyTests.cs with full test coverage for:

  ✅ Pipeline required by enabled branch policy → Returns true
  ✅ Pipeline with disabled branch policy → Returns false
  ✅ Pipeline not in branch policies → Returns false
  ✅ Repository with no build policies → Returns false

Business Impact

Benefits Delivered

1. Reliability: Pipeline ID-based matching eliminates display name mismatch issues
2. Accuracy: Correct branch policy detection regardless of naming differences
3. User Experience: "Report build status" checkbox properly maintained when required

Validation Results

Test Coverage

• Status: All 6 branch policy tests passing (100% success rate)
• Command: dotnet test --filter AdoApi_BranchPolicyTests
• Result: Passed! - Failed: 0, Passed: 6

Build Quality

• Status: Clean compilation with zero warnings
• Command: dotnet build --verbosity minimal
• Result: Build succeeded. 0 Warning(s) 0 Error(s)

Usage

No changes required for end users - trigger preservation happens automatically:

gh ado2gh rewire-pipeline --ado-org myorg --ado-team-project myproject --pipeline-id 123 --repo myuser/myrepo --service-connection-id sc456

The command will now automatically preserve all original pipeline trigger configurations during the migration process.

[Copilot]

Pull Request Overview

This PR implements automatic preservation of Azure DevOps pipeline trigger configurations during migration to GitHub, with intelligent detection of branch policy requirements to determine when pull request triggers should be enabled.

• Adds branch policy checking to determine if pipelines are required by build validation policies
• Modifies trigger handling to preserve original configurations while enabling proper GitHub integration
• Implements comprehensive test coverage for the new branch policy detection functionality

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/ado2gh/Commands/RewirePipeline/RewirePipelineCommandHandler.cs	Updated to pass trigger data from pipeline retrieval to pipeline modification
src/OctoshiftCLI.Tests/ado2gh/Commands/RewirePipeline/RewirePipelineCommandHandler_TriggerPreservationTests.cs	New test file covering trigger preservation scenarios
src/OctoshiftCLI.Tests/ado2gh/Commands/RewirePipeline/RewirePipelineCommandHandlerTests.cs	Updated existing tests to handle new trigger parameter
src/OctoshiftCLI.Tests/Octoshift/Services/AdoApi_PullRequestValidationTests.cs	New comprehensive tests for pull request validation enhancement logic
src/OctoshiftCLI.Tests/Octoshift/Services/AdoApi_BranchPolicyTests.cs	New test suite for branch policy detection functionality
src/OctoshiftCLI.Tests/Octoshift/Services/AdoApiTests.cs	Updated existing API tests to accommodate new trigger handling
src/Octoshift/Services/AdoApi.cs	Core implementation of branch policy checking and enhanced trigger management
global.json	Updated .NET SDK version
RELEASENOTES.md	Added release note for the new trigger preservation feature

[github-actions]

Unit Test Results

  1 files    1 suites   10m 24s ⏱️
918 tests 918 ✅ 0 💤 0 ❌
919 runs  919 ✅ 0 💤 0 ❌

Results for commit 97e5c39.

♻️ This comment has been updated with latest results.

[georgy-gorelko]

@boylejj anyone can assist with review?

[dylan-smith]

I might consider extracting all that pipeline trigger logic out of AdoApi (which is intended to be relatively thin wrapper around calling ADO Api's, and not behavior-rich) and into a separate service which sits on top of AdoApi.

[danquirk]

PR description confused me a bit because there are so many meanings of trigger across ADO+GH+yml+pipelines:

Yours says:
Before: After migration, pipelines would only build on manual triggers or CI pushes. Pull request triggers and build status reporting had to be manually configured in Azure DevOps UI.
After: All original trigger configurations (pullRequest, continuousIntegration, etc.) are automatically preserved during migration. The system now checks Azure DevOps repository branch policies before rewiring and the infrastructure is ready for enabling PR triggers based on branch policy requirements.

My now understanding is:
Before: After migration, ADO pipelines have a pull request trigger added which overrides yaml pull request triggers and disables pull request validation, breaking existing PR validation workflow (screenshot of this UI might be illustrative)
After: After migration, ADO pipelines which were required by ADO branch policies will no longer have the 'overides yaml pull request triggers' or 'disable pull request validation' options set, preserving existing pull request validation behavior from the pipeline when ADO branch policies are translated into GH Checks during migration (already done by the migration tool).

[georgy-gorelko]

I might consider extracting all that pipeline trigger logic out of AdoApi (which is intended to be relatively thin wrapper around calling ADO Api's, and not behavior-rich) and into a separate service which sits on top of AdoApi.

Did code refactoring as per suggestion

[offbyone]

I have concerns about API call performance for repeated invocations.

[begonaguereca]

@georgy-gorelko the logic you have in place all seems sound to rewire pipeline triggers post migration, do you have any mannual testing you've done of these changes?

I am not sure why our ADO int tests havent run either I would feel more confident if we can show those passing

[georgy-gorelko]

@georgy-gorelko the logic you have in place all seems sound to rewire pipeline triggers post migration, do you have any mannual testing you've done of these changes?

I am not sure why our ADO int tests havent run either I would feel more confident if we can show those passing

Yes, I have run CLI locally to rewire pipelines upon migration. Here's example before/after CLI changes

PR Triggers BEFORE:

PR Triggers AFTER:

Build Status BEFORE

Build Status AFTER

@begonaguereca I don't know what's the process of triggering remaining tests would be and why those not firing. Hopefully DRI team can review and assist with the needful runs

[begonaguereca]

@georgy-gorelko why are you merging into github-main vs main

[begonaguereca]

Im running the int tests manually here https://github.com/github/gh-gei/actions/runs/17305685659

[begonaguereca]

@georgy-gorelko the ADO token was expired, I just updated it

[begonaguereca]

Hey! Once the int tests pass this is good to go 👍🏽

[begonaguereca]

@georgy-gorelko I am working on fixing the CI issue, but the migrations are passing in the end. I think we can merge without the remaining ones passing

[offbyone]

Good to ship pending testing

[begonaguereca]

I've got the CI working for everythign less BBS working on getting the server up again for BBS

[begonaguereca]

Ok all the CI issues have been resolved @georgy-gorelko if you would like to merge this in so we can review the other PR's that depend on this

[DkSkydancer]

Ok all the CI issues have been resolved @georgy-gorelko if you would like to merge this in so we can review the other PR's that depend on this

@begonaguereca Geogry is on vacation and I'm his team mate and stand-in.

I was on vacation while this was proposed and i am not sure why we would turn of the override of yaml triggers? was that something you/your team discussed with Georgy?

A lot of ADo pipelines has branch policies and ultimately the tool (probably?) needs tro translated that in to yaml triggers?

[github-actions]

Package	Line Rate	Branch Rate	Complexity	Health
gei	80%	72%	574	✔
bbs2gh	83%	77%	653	✔
ado2gh	83%	77%	619	✔
Octoshift	85%	73%	1631	✔
Summary	84% (7503 / 8967)	74% (1781 / 2393)	3477	✔