Rewire Pipelines

Rewire Pipelines

Rewire pipelines is the stage of a wave page that follows Move Repositories. It is there when the plan rewires the repositories it moves, from Azure DevOps, GitLab, or both.

The stage rewires what the wave moved, in each destination org, in one of two ways:

• Azure DevOps pipelines keep running in Azure Pipelines. The sandbox's rewire decisions are carried into the destination org, update pull requests point references at the GitHub copies, and the pipelines are rebound to them. See Rewiring Azure DevOps Pipelines.
• GitLab projects pull from their GitHub copies, so their pipelines keep running in GitLab. See Rewiring GitLab Projects.

A destination org that takes both has a card for each.

Rewiring Azure DevOps Pipelines

For Azure DevOps, the rewire carries the sandbox's decisions into each destination org, in order:

1. Start the rewire. Each org scans the wave's copies and previews how the sandbox's decisions land there.
2. Apply each org's preview. That org's update work, including its update pull requests, then runs on its own Prepare for rewire.
3. Rebind the pipelines from the wave, once they are approved in that org.
4. Follow how the pipelines are running, and send follow-up updates to repositories in other waves that reference what this wave moved.

For how the dry run's decisions split, see Prepare the Rewire.

Start and Apply the Rewire

On Rewire pipelines, above the dry run's estimate, you run the rewire in each destination org. Until you start, it reads Nothing is rewired yet. Nothing is written in a destination org until you apply a preview.

1. Choose Start the rewire. CodeCargo scans the wave's copies in each destination that can start and previews how the sandbox's decisions land there. An org that already has a preview, an apply, or a failure is not started over.
2. Read that org's card. Its badge reads Not started, Scanning, Previewing, Preview ready, Applying, Applied, or Failed. The card also shows how many of the wave's repositories moved there, and how many have not. A card that cannot start lists why. Repositories that have not moved join once their move is retried. Choose Preview again to take them in.
3. When the preview is ready, choose Apply in the org and confirm. The dialog says how many decisions apply as they are. That org's own decisions stay as they are. If the apply fails, the card says why. Apply again sends the same preview without asking, and what already landed is kept.

If an org finds no pipelines to scan the wave's repositories with, import their Azure DevOps pipelines in the sandbox first. The plan copies them from there.

A preview counts decisions that apply as they are, that changed since the dry run, that need a target here first, that were not found here, that were already decided here, that are kept as they are here, and that are invalid. Of those that need a target, the card says what each one waits on: a repository still to move here, one in another destination org, one that stays in Azure DevOps, one with no destination or wave yet, or one this org has not mapped. For a repository in another destination org, see When a Decision Waits on Another Org. Edits the sandbox left out of update pull requests are counted on their own.

Once applied, the card follows that org's update work the same way its Prepare for rewire page does: questions still open, findings to review with AI, repositories ready for an update pull request, update pull requests open, and how many have merged. The ready and open counts open those lists. The card also opens that org's Prepare for rewire limited to this wave, with a filter that reads Wave N. See Limited to a Migration Run or a Wave. When the org is linked to more than one Azure DevOps organization, each one has its own row, labeled with its name.

As it rewires a destination org, the plan also records on that org's repository mapping where each repository its references name moves, and when. See In a Plan's Destination Org.

Above the cards, and on the stage strip once an org has started, you see how many destination orgs have applied and, when update pull requests are needed, how many have merged. The strip warns when an org has failed.

Preview again, Apply in the org, and Apply again show only when you can take that step and the org is not blocked. Once applied, rebind the pipelines from the card. See Rebind, Roll Back, or Check from the Wave.

Rebind, Roll Back, or Check from the Wave

Once an org's rewire is Applied, each Azure DevOps organization on its card has a row for its pipelines. You approve pipelines on that org's Prepare for rewire, and run the jobs from here. The row says how many of the wave's pipelines are approved, such as 12 pipelines approved, or No pipelines approved yet. Approve them in the org's Prepare for rewire. Once a rebind has used the approvals, it says how many are rebound.

• Rebind in the org switches the approved pipelines from Azure Repos to the repositories the wave moved. With more than one Azure DevOps organization, the button names it, such as Rebind acmebank in acme-data.
• Roll back puts each rebound pipeline of the repositories the wave moved back on its Azure Repos repository, with its original triggers. Other edits made since the rebind stay as they are. Its approval is withdrawn, so approve it again to rebind it.
• Check and repair checks each of the wave's pipelines in Azure DevOps. Where a pipeline's pull request trigger doesn't match the build validation policies on its original Azure Repos repository, CodeCargo adds, fixes, or removes the trigger. Nothing else about a pipeline changes. Pipelines still on Azure Repos are left alone and counted as waiting for the rebind. The check skips verified and repaired pipelines unless you turn on Recheck verified and repaired pipelines.
• While a job runs, the row says how far it has got, and Cancel rebind, Cancel rollback, or Cancel check stops it.

Each job asks you to confirm. The dialog says whose Azure DevOps sign-in it uses, which is whose name Azure DevOps shows on its changes. A destination org that links the Azure DevOps organization itself uses its own sign-in. Otherwise you are starting it from the plan, so CodeCargo uses the plan's sign-in: its service principal, or the personal access token someone added. When the plan links Azure DevOps with one person's token, the row suggests Microsoft sign-in instead, which shows CodeCargo's service principal and doesn't stop when that token expires.

A job is refused, and the row says why, unless the org's rewire is applied, the plan links that org, you can rewire repositories there, and the org is not a dry run. It also waits while another job runs on the same Azure DevOps sign-in. Each job is recorded in both orgs' audit logs, and its detail stays on that org's Prepare for rewire. See Access the Rebind Needs.

How the Pipelines Are Running

Once an org's rewire is Applied, each Azure DevOps organization on its card shows a Pipelines line under its progress. The line says how the pipelines on this wave's copies stand in that organization's Verify stage, for example Pipelines: 38 passed · 2 to review · 20 waiting · 280 not rebound. A count of zero is left off. N not watched is added when any pipeline is not watched.

Each count opens that organization's Prepare for rewire, limited to this wave, on Verify with its list selected: passed opens Passed, to review opens Needs you, and not watched opens Not watched. Not rebound counts pipelines that have not been rebound yet. Verify keeps those in Waiting; here they are split out from waiting, and the two add back up to Waiting. Both open Waiting.

The line does not hold up the wave. It stays hidden until that org's rewire is applied, and when there is nothing to count. Follow-ups do not show it.

Other Destination Orgs

On Rewire pipelines, Other destination orgs names the destination orgs this wave's references point into, outside each repository's own. The row is hidden when there are none.

It reads 4 references from this wave point at repositories in those orgs, rewired with a service connection that can read those orgs. Each org is named. A reference counts once for each pair of repositories, the same way Review dependencies counts them. Both repositories need a destination. A pair in the same org does not count, and neither does a repository with no destination yet.

Every pair counts, including a repository many others reference. Decide destinations leaves those shared hubs out when it weighs where repositories should go, so a count there can differ. See No GitHub Service Connection Yet for the connection those orgs need.

References That Wait for a Later Wave

Rewire pipelines also says which later waves this wave's references wait for, in the order the waves move. It reads 3 references wait for wave 4 and 2 for wave 6, or 1 reference waits for wave 4. The line is hidden when none wait for a later wave. A reference to a repository that is not in a wave yet is left out.

These references do not keep the wave from moving. They wait in the destination org and are rewired when that later wave moves. A template repository that moves later is still named on the wave page's Ready to move when list. See Template Repositories.

What the AI Review Follows

On Rewire pipelines, an AI review row names whose directives each destination org's review follows. plan's directives opens Pick features.

• Follows the plan's directives when only the plan has them.
• Follows the plan's directives, then this wave's own when both do.
• Follows this wave's directives when only this wave does.

The row is hidden when neither has any. Blank text counts as none.

In a destination org, Review with AI follows those directives for a repository this one wave moved there. The plan's come first, and this wave's own follow. The review reads them when it starts, including a re-review, and it does not matter whether you started the review with the page limited to this wave. A repository that no plan wave moved here is reviewed without them. So is one that more than one wave moved. An abandoned move does not count.

Follow-Up Updates

Repositories in other waves that reference this wave's repositories kept those references on Azure DevOps. A note on Rewire pipelines says who needs a follow-up. They need one only once they have moved. A repository that has not moved is rewired by its own wave, not as a follow-up of this one.

Before this wave's repositories have landed in every destination org, the note estimates who will need a follow-up. It includes repositories in waves scheduled before this one, even one that has not moved or has no destination yet, and any repository in another wave that has already moved, such as a later wave that moved first. A later wave that has not moved is left out.

Once this wave's repositories have landed, only repositories that have moved still count, so an earlier wave that has not moved drops out. The note names those repositories and their waves, for example 2 repositories in wave 3 reference 1 repository this wave moved, and says they need rewiring again: a fresh scan of just those repositories, then a follow-up update pull request for each. Before the wave lands, it says to rewire them once this wave's repositories land.

Each destination org's card lists only repositories that have already moved there and still have a copy that is not archived. It reads 3 repositories in waves that have already moved reference what this wave moved. A repository that moved with no copy is never included, on the card or in the note. When those cards are showing and the wave's repositories have landed, the note is hidden.

On Rewire pipelines, follow-ups sit at the bottom of the org's card. These are repositories in other waves that have already moved and still reference what this wave moved. An org with nothing of this wave's own gets a card of its own for them.

The card says how many repositories in waves that have already moved reference what this wave moved, whether that org is being scanned, and whether its latest scan is from before this wave's moves. Follow-ups waiting on a moved repository's own update are listed, with which update they wait for. What keeps the follow-ups from starting is listed on the card.

1. Choose Start follow-ups in the org while it needs a scan. That scans the org first. While the scan runs, the card reads Scanning the org and does not offer the button.
2. Once the scan covers the moves, choose Open N follow-up pull requests. That opens the ready rows that are not waiting.

Open and merged follow-up pull requests are counted the same way as that org's Prepare for rewire page, and the count links to the open list. Open the follow-ups in the org's Prepare for rewire opens that page on the runs that copied those repositories. When the org is linked to more than one Azure DevOps organization, each one has its own line, labeled with its name, its own counts, and its own link.

A warning names pipelines that have a repository trigger on a moved repository. That trigger stops firing once they are on GitHub. Review the questions in the org's Prepare for rewire opens those questions. With more than one Azure DevOps organization, each one has its own review link. The warning counts every such pipeline in the org; a review link opens that organization's questions, not the whole count.

If the org finds no pipelines to scan the follow-ups' repositories with, import their Azure DevOps pipelines in that org, or in the sandbox for repositories the plan moved there. Start the follow-ups again once they are imported.

Rewiring GitLab Projects

When Rewire pipelines is on for GitLab, each destination org the wave moves GitLab projects into has a GitLab mirror card on this stage, beside any Azure DevOps card. Applying it gives each project a pull mirror of its GitHub copy and has it report pipeline status to that copy, so its pipelines keep running in GitLab. Turn the step on under Rewire GitLab Projects. It is off until you do.

The card counts how many projects moved, are ready, can't be rewired, are rewired, or need Undo. Its table lists each Project, its GitHub copy (or Not moved yet), and where it stands under Check, Mirror, and Rewire. What keeps the card from applying is listed under Can't apply in the org yet.

The wave's rewire is done once every project that can be rewired is pulling from its copy. A project that can't be rewired does not hold the wave. That includes a project whose group has no pull mirroring, and one the move did not copy. The card then reads Every project that can be rewired is., and the table says why the rest can't be.

While Close out is making a project read-only, Apply leaves that project out and names it. Apply again once that finishes.

Checking, applying, and undoing need the Migration Assistant manage permission in the sandbox. One change of a GitLab connection runs at a time. While one runs, the card says so, and Apply and Undo wait.

Check the Projects

Choose Check the projects first. Nothing changes in GitLab until you apply. The check reads whether each project can be rewired: its license, the role CodeCargo has on it, whether it is archived, and whether it is already mirrored. A project's Check reads Not checked, Checking, Ready, Can't rewire, or Check failed.

Check again reads them again. The Mirror column shows how a mirror is doing, in GitLab's own words, as of the last check. An apply runs no check, so a mirror just set reads Set until you check again.

A project that has not moved yet is checked like the others, and rewired once it moves. Only a moved project that is Ready is applied.

Apply the GitLab Rewire

Apply opens Apply the GitLab rewire in the org. It says how many projects get a pull mirror of their GitHub copy and report pipeline status to it. Choose how GitLab picks up new pushes, then give the tokens:

• GitHub personal access token (classic) - GitLab keeps it to pull from each GitHub copy and to report pipeline status.
• GitLab personal access token - a service account's token with the api scope and the Maintainer role on these projects. Do not use a project or group access token. The mirror belongs to the token's account, and revoking a project or group token turns the mirror off.

Once every project that can be rewired is, the button reads Apply again, which sets them again. A project's Rewire column reads Not set, Applying, Set, Undoing, or Needs Undo. Under Set, it says what was set, such as Mirror and status reporting set., and how the project hears about pushes. A project whose GitHub copy changed since it was rewired reads Needs Undo: undo it, then apply again. An apply is refused when a project is already rewired to another GitHub copy. Undo that first.

How GitLab Picks Up New Pushes

The Apply dialog asks how GitLab picks up new pushes to each GitHub copy:

• Webhook - GitHub tells GitLab to pull right after each push. It needs GitLab 19.2 or later, or gitlab.com, and two more tokens. GitHub token for the webhook needs admin:repo_hook. It is used once to add the webhook to each GitHub copy, and not kept. GitLab token for the webhook is a fine-grained personal access token with only Pull Mirror: Create. GitHub sends it to GitLab with each push. Webhook is not offered when the check found that none of the projects can take it. A project that can't falls back to polling.
• Relay - CodeCargo gets each push and tells GitLab to pull, for a GitLab that GitHub can't reach. Set the relay token on the sandbox's GitLab connection first, under Connections: a group access token with the Maintainer role and the api scope, or, on GitLab 19.2 or later, a fine-grained personal access token with only Pull Mirror: Create.
• Polling - GitLab checks for new commits on its own schedule, so they show up later than with the other two.

A rewired project's Rewire column reads Webhook working., CodeCargo tells GitLab about each push., or Polling only. When a webhook fell back to polling, it says why.

Undo the GitLab Rewire

Undo opens Undo the GitLab rewire in the org. CodeCargo removes the pull mirror, status reporting, and webhook it set on the projects it rewired, including those that need Undo. Their GitHub copies stay as they are.

• GitLab personal access token - a token with the api scope and the Maintainer role on these projects.
• GitHub token for the webhook - needs admin:repo_hook, to remove the webhook from each GitHub copy. It is used once, and not kept. It is required while a project has a webhook on record. Otherwise it is optional, and its hint says when it is still worth giving, such as after an apply that may have added a webhook it didn't record.

An undo is refused when CodeCargo rewired none of these projects. Close out treats an undone project as moved. See After You Undo a Rewire.