GEI - Rewire Pipelines

Part 4 - Rewire Pipelines

This is #4 in a series of articles explaining how to use the GitHub Enterprise Importer (gei) tools to migrate repos from Azure DevOps to GitHub. If you have not already done so you should read this article first to get yourself set up, so you can try the examples.

Here are the preceding articles:

1. GitHub Enterprise Importer (GEI)
2. GEI Generate Script & Inventory Report Commands
3. GEI — Migrate Repo

Now that we have migrated a repo that was being built and/or released by Azure Pipelines, you likely want to continue building and deploying that code. To do this there are two commands you may find useful, share-service-connection and rewire-pipeline.

share-service-connection

This command shares an existing GitHub Pipelines App service connection to other team projects. What does that mean? When you install the Azure Pipelines GitHub application it will create a service connection in Azure DevOps so your pipelines can communicate with your GitHub Repos. It also creates a Service Connection in the Team Project you select.

The share-service-connection command allows you to easily share that to each of the Team Projects in your Azure DevOps Organization.

The Manual way

Looking at the Service Connection’s security settings on the team project it was created in, you will see a section that allows you to share it to other projects by clicking the + button in the top right.

If you are not sure how to get to here: This bread crumb trail might help:

Project Settings > Service Connections > “Select your GitHub Service Connection” > Top right Ellipsis > Security > Project Permissions.

Now you should see your service connection in the project you shared with.

The Automated way

Instead of all that, you can use GEI and the share-service-connection command to do the same thing.

gh ado2gh share-service-connection `
    --ado-org "dlloyd" ` #Azure DevOps Organization 
    --ado-team-project "ADOShuttle" ` #The Team project you are shareing to
    --service-connection-id "TheIdCopiedFromTheServiceConnection"

You can easily get the id of the Service Connection by opening the service connection from project settings. The Id is right there in the URL.

Blacked out in the diagram for my protection.

Running this command will share the service connection with the Team Project passed to the command.

But wait…

I have a scenario when you don’t want to use the share-service-connection command. I won’t explain that here, instead I’ll point you to an article I wrote back in March “Azure Pipelines Shared Service Connections to GitHub”

Now that we have that out of the way, lets rewire our pipeline to pull the code from the newly migrated repo in GitHub.

rewire-pipelines

Assuming you have already shared your service connection to all the appropriate Team Projects. Lets take a look at the rewire-pipeline command.

This command can be used to switch the repo on the pipeline to the newly migrated GitHub repo.

At the moment the pipeline “Get Sources” will look something like this:

We want to switch it to something like this:

This can be done with one call to the rewire-pipeline command, which takes 6 arguments:

1. Azure DevOps Org
2. Azure DevOps Team Project
3. Azure Pipeline
4. GitHub Org
5. GitHub Repo that was migrated
6. Azure DevOps Service Connection ID

gh ado2gh rewire-pipeline `
    --ado-org "dlloyd" `
    --ado-team-project "EmployeeServices" `
    --ado-pipeline "shuttleServiceBuild" `
    --github-org "MyShuttle" `
    --github-repo "New-ShuttleService" `
    --service-connection-id "TheIdCopiedFromTheServiceConnection"

Easy as that!

Now lets add this to our full migration script.

Take note of the comments about the $ado_build argument. If you have a standard name for pipelines you can figure this out in the script so you don’t have to pass it in. If you don’t you can just pass it in to the script.

In my script I give the option to pass it in or use the repo name as the build name, which is assumed to be the standard in this case.

param (
    [Parameter(Mandatory=$true)] $ado_repo,
    [Parameter(Mandatory=$true)] $ado_project,
    $ado_build, # Only required if the build is not a determinable name
    $gh_repo # Only Required when Repo should not be prefixed with the project
)
# check to make sure we have the required Tokens for access to GitHub and AzDO
if (!$env:ADO_PAT) {
    write-host "Missing ADO_PAT Environment Variable"
    exit
}

if (!$env:GH_PAT) {
    write-host "Missing GH_PAT Environment Variable"
    exit
}

# These might need to be paramaters depending on your situation
$ado_org="dlloyd"
$gh_org="GHShuttle"
# Service Connection Id
$serviceConnectionId="TheIdCopiedFromTheServiceConnection"

# if gh_repo was supplied use that for the GitHub Repo Name 
# otherwise use the ADO repo name prefixed with the ADO Project Name
if ( !$gh_repo ) { $gh_repo="$ado_project-$ado_repo" }

# if ado_build is supplied us that for the build name
# otherwise use whatever cosistant pattern you have for pipeline names
# ie same as the repo name
if ( !$ado_build ) {$ado_build=$ado_repo}

# Make the ADO Repo read only 
gh ado2gh lock-ado-repo `
  --ado-org "$ado_org" `
  --ado-team-project "$ado_project" `
  --ado-repo "$ado_repo"

# Migrate the Repo
gh ado2gh migrate-repo `
  --ado-org "$ado_org" `
  --ado-team-project "$ado_project" `
  --ado-repo "$ado_repo" `
  --github-org "$gh_org" `
  --github-repo "$gh_repo" `
  --wait

if ($LASTEXITCODE -eq 1)
{
    write-host "Migration Failed" -ForegroundColor Red
}
else
{
  write-host "Migration Successful" -ForegroundColor Green
  # Disable the ADO repo 
  gh ado2gh disable-ado-repo `
    --ado-org "$ado_org" `
    --ado-team-project "$ado_project" `
    --ado-repo "$ado_repo"

  # Rewire the pipeline to the new build 
  gh ado2gh rewire-pipeline `
    --ado-org "$ado_org" `
    --ado-team-project "$ado_project" `
    --ado-pipeline "$ado_build" `
    --github-org "$gh_org" `
    --github-repo "$gh_repo" `
    --service-connection-id "$serviceConnectionId"
}

In the next article we’ll tackle Teams and User permissions.