Configuring an Azure DevOps Pipeline to use a GitHub Repository

As well as using its internal Git repository capability Azure DevOps can instead use externally linked GitHub repositories. This page descibes the minor changes required in order to support this configuration.

Connecting Azure DevOps and GitHub

You can create the connection between ADO and GitHub a number of different ways: Build GitHub repositories - Azure Pipelines

The simplest way is to use a Service Connection using a GitHub classic Personal Access Token (PAT). Ensure the PAT has access to all of the repositories you want to use within your ADO environment. You will need to to use multiple repositories with Azure DevOps (the source repository and also the Compliance repository), so register the PAT against a user account as registering a PAT against a repository will only enable access to that repository as the same PAT cannot be used against multiple repositories.

Configuring your CI/CD pipelines to use your GitHub repository

Start by selecting your CI/CD pipeline in ADO and updating its source repository:

1. Open the Pipeline.

2. Click on Edit.

3. Click on the ⠇ (dots) menu and select Triggers.

4. Select the YAML tab and then Get sources.

5. Select the GitHub source and complete the details based on your preferred authentication method.

Modifying your CI/CD pipelines to use GitHub

The CI/CD pipeline examples provided for Azure DevOps require some minor, unavoidable modifications when using them with a GitHub repository.

The static code analysis (compliance) step performs a checkout: self which checks out repository under an ADO agent’s C:\agent\_work\<worker_number>\s\<RepoName> folder. To construct the correct asset path the default pipeline example supplies step parameter ${{ parameters.SourceRepoName }} with the value $(Build.Repository.Name).

When using a GitHub repository, the $(Build.Repository.Name) value maps to Organization/RepositoryName which generates an invalid asset path of C:\agent\_work\worker_number\s\<Org>/<RepoName> meaning the mettleci compliance test command will be unable to find the relevant job assets and will fail.

The amendments to the CI/CD pipeline necessary to remedy this are as follows:

Supply a repository name to build the correct asset path

We need something to specify the path based on the defined source repository name, so we add the path property

  - checkout: self
    path: s/${{ parameters.SourceRepoName }}

Nxt, we’ll inform the pipeline agent that it’s using a remote, non-Azure DevOps repository. The existing resources definition…

resources:
 repositories:
 - repository: Compliance
   type: git
   name: Azure-Compliance

… needs to be modified with some additional properties to use a GitHub repository:

resources:
  repositories:
    - repository: Compliance
      type: github
      name: GitHubOwner/Compliance
      endpoint: MyGitHubServiceConnection
      ref: refs/heads/main

Elsewhere we use a variable (named ComplianceRepoName) which should be assigned a value which matched the name property used in the resources section:

variables:
  - name: BaseIISProjectName
    value: ADOGitHubTest                 # Set the base name of your project here!
  - name: ComplianceRepoName
    value: GitHubOwner/Compliance        # Set the name of your Compliance Rule repository here!
  - name: ComplianceFatalTags
    value: 'fail-ci'                     # Set the tag you use to identify fatal Compliance Rule here!         
  - name: PS_SpecialHandling
    value: true

You should also update the checkout step for the Compliance to use this same variable:

  - checkout: Compliance
    path: s/${{ parameters.ComplianceRepoName }}