Pipeline rewiring not working

[AdamWorley]

Description

I am using the latest version of github/gh-ado2gh 1.19 and I am able to generate the migration script for moving repos from ADO to our own GHE enterprise, the repo's move over generally without issue however the pipeline re-wiring just doesn't seem to work anymore.

Here's an example of the logs for the rewiring step for a repo using the classic pipelines.

[2025-10-01 13:51:37] [INFO] Rewiring Pipeline to GitHub repo...
[2025-10-01 13:51:37] [INFO] Looking up pipeline ID for: \EmailService - PR Dev
[2025-10-01 13:51:38] [INFO] Using resolved pipeline ID: 187
[2025-10-01 13:52:39] [WARNING] HTTP error during branch policy check for pipeline 187 in EmailService: Response status code does not indicate success: 404 (Not Found).. Pipeline trigger configuration may not preserve branch policy requirements.
[2025-10-01 13:52:39] [INFO] ADO Pipeline ID = 187 is NOT required by branch policy - preserving original trigger configuration
[2025-10-01 13:52:39] [WARNING] HTTP error retrieving pipeline 187 in [project]: Response status code does not indicate success: 400 (Bad Request).. Skipping pipeline rewiring.
[2025-10-01 13:52:39] [INFO] Successfully rewired pipeline
[2025-10-01 13:52:40] [WARNING] GitHub is currently experiencing availability issues.  See https://www.githubstatus.com for details.

There is a branch policy in place but it seems like this isn't detected and the pipeline isn't even updated to use our GHE even if the status check hasn't been configured.

Reproduction Steps

Run a rewire-pipeline command using PAT token authentication for ADO and GHE

gh ado2gh rewire-pipeline --ado-org "{org-name}" --ado-team-project "{project-name}" --ado-pipeline "{pipeline-path}" --github-org "{gh-org}" --github-repo "{repo}" --service-connection-id "{connection-id}"

and get the above output in response.

Manually re-wiring

In an attempt to re-wire the pipeline just so that the repo and pipeline have been moved together for this repo I updated the pipeline to point to the relevant GHE repo and added the status check for a PR, however when a PR is raised the status just get's stuck saying "Expected — Waiting for status to be reported", if I manually trigger the pipeline for the relevant branch the status updates in GH so it seems like the PR trigger isn't working in ADO as I can see the webhook request was sent with a 200 response.

Any help with this would be great - thanks in advance, Adam

[begonaguereca]

Moved it our migration friction project board

[shinji62]

@begonaguereca @georgy-gorelko Wondering when your team will be able to take a look on this issue, I plan to use the rewire function by the end of the month.

So would like to know if this issue will be resolve or this is something expected or not. Thanks

[georgy-gorelko]

Can you confirm the following results:

• Pipeline ID =187 has ADO branch policy set?
• Instead of --ado-pipeline use --ado-pipeline-id. Same output?
• While supplying --ado-pipeline argument, use pipeline name (not folder)

[AdamWorley]

Hey @georgy-gorelko,

Yes the pipeline has a branch policy and I have tried both the --ado-pipeline and --ado-pipeline-id options and they result in the same thing; I can see in the logs for the one that takes the pipeline name are correctly fetching the same pipeline id so that doesn't appear to be an issue.

I have tried providing just the name as well as the full path and only the full path option works.

After doing some digging and editing the gh-gei tool it seems like the issue with getting the policies is due to the repository being disabled before it attempts to fetch the policies which makes sense as to why the pipeline is found but no policies are.

I did also find another issue in that the project name seems to be prefixing the repository name which was also causing a 404, you can see the changes I made here.

The only issue that seems to be left after making those changes that address the above is that once the pipeline has been re-wired I need to run the relevant pipeline after the migration and re-wire, before I'm able to configure the pipeline as a status check for the relevant branches

[georgy-gorelko]

Yeah, repository implied to be active to be able to fetch the policy. CLI could be enhanced to provide more specific details on what is root cause of the failure though.

With regards to project name prefixes not sure if that was initially designed that way but I can foresee issues when doing bulk migrations from various projects where repository names match may result to name conflicts.

Pipeline has to be run at least once to be able to be configured for the branch policies. I made a change to run migration in a test mode (when pipeline is rewired to GitHub, pipeline is kicked-off in ADO, then rewired back to ADO). The argument name is --dry-run. This way any rewiring process can be tested before actual rewiring takes place.

[tambling]

Quick note here: I'm on the team that maintains GitHub's GEI functionality, and I had assigned myself to this issue with the intention of taking a look, but @georgy-gorelko has quite capably beaten me to it (thank you!)—my on-call rotation has ended, so I'm going to unassign myself, but this issue remains on the team's radar if back-end changes are needed.

[jfine]

Sorry for the delay. Will get 👀 on this as soon as we can but at the moment on-call is overwhelmed. Wanted to let you know that we haven't forgotten about you!

[begonaguereca]

Hi folks! Do to the thanksgiving holiday the Migration tooling team is a little backed up. We will do our best to get through these tickets as quickly as we can. Thank you!

[begonaguereca]

Hey @AdamWorley and @georgy-gorelko checking in, are we needing anything from our side at the moment?

[AdamWorley]

Hi @begonaguereca and @georgy-gorelko,

Not really sure who this is most relevant to but even after updating to the latest version of the tool I can see in the logs that querying the repos for branch policies results in 404s and this still appears to be due to the migration script prefixing the repo name with the project name when making the query, if I manually make the same call and remove that prefix the response comes back without issue. I hope this helps.

I've not gotten much further with the branch policies being applied either and have actually found a strange issue where when manually updating the pipelines to point to GitHub and then configuring a dev and main branch validation rule with the respective pipelines (one dev and one main pipeline) that both pipelines are triggered on a PR into dev, overriding the PR branch rules in ADO stops this from happening but it does seem odd that specifically picking a pipeline for each branch still ends up running both.

[begonaguereca]

@georgy-gorelko are you able to dig in and replicate @AdamWorley's scenario?

[georgy-gorelko]

I was able to repro 400 error initially reported when ADO repo is disabled. Ideally rewiring should not lead to confusions if ADO repo is disabled. I have raised a PR with multiple error handling and messaging enhancements to make it clearer. @begonaguereca please check PR. I suggest to give it another try once PR merged and new version of tool released. As for the manual rewiring issues it does not seem related to CLI. I recommend to open separate issue with clear repro steps to assist further.

[brianaj]

@AdamWorley catching up on this issue now. Were thing previously working on older releases before v1.19.0? You should be able to do something like gh extension install github/gh-gei --version 1.18.0 to confirm but for ado extension.