Using multiple repositories within Azure DevOps pipelines
In numerous situations I have seen seen people sharing code from a centralized Azure Repos sending the scripts via email. On every new version they would send out a new version. Working with Azure DevOps this isn't a preferred solution, as you do not know how the script is being used and when there is a bug in the script there is no real fast option to update all distributed scripts.
This is where the option comes in to checkout multiple repositories within you Azure DevOps Pipeline. The rest of the article guides you trough the process of setting this up.
Different Azure DevOps Organization
When a repository from a different organization is one of the requirements a Service Connection is a prerequisite. This service connection will be used to setup the connection between the organizations by using a Personal Access Token. Depending on the use case make sure you generate a PAT with the correct permissions. Usually I generate a PAT with read permissions.
Within the project were the pipeline will be created create a new service connection of the type "Azure Repos / Team Foundation Server". In the creation dialog fill in the PAT en the organization and click verify to check the connection.
Checking out multiple Azure Repos
Loading repositories is completely handled from within the pipeline and currently the below repository types are supported:
- Azure Repos Git
- Github
- Github Enterprise
- Bitbucket cloud
For this article we use multiple Azure DevOps repositories. Within the pipeline the other repositories are specified by using the "resources" option were in a "repository" is specified.
Check out code from different organization
As mentioned above to check out code from a different organization the service connection needs to be created and specified within the repository reference.
resources:
repositories:
- repository: [Name for reference in your Pipeline]
endpoint: [The created Service Connection]
type: git
name: [Project]/[Github Repository]
ref: [Branch]
The above code snippet shows which information needs to be supplied for making the connection.
Check out code from the same organization
Checking out code from the same organization requires not that much steps to get up and running and can be done directly from the "checkout" step from within the pipeline.
- checkout: git://[Project name]/[Repository]@[Branch]
I personally like to specify the repository completely as I'm then also able to supply the name that I would like to use within the check out step.
resources:
repositories:
- repository: [Name for reference in your Pipeline]
name: [Github Repository]
type: git
ref: [Branch]
Putting all Azure Repos together
When this is all in place you can checkout the different repositories within the pipeline within the stages were you need the sources. The current repository of the pipeline is referenced by the keyword "self" and the others are referenced by there name specified within the resources.
resources:
repositories:
- repository: DifferentOrganization
endpoint: Repos - MSFTPlayground
type: git
name: msft-ccoe/msft-ccoe
ref: master
- repository: SameOrganization
name: Azure DevOps Discovery/Governance
type: git
ref: master
trigger:
- none
pool:
vmImage: 'windows-latest'
steps:
- checkout: self
- checkout: DifferentOrganization
- checkout: SameOrganization
- script: dir $(Build.SourcesDirectory)
Where are the files checked out to?
Normally when using just the current repo the files are saved directly within the "$(Build.SourcesDirectory)". With multiple repositories configured for each reference a folder is created based on the repository name. This is shown by the output of the above reference yml file.
Conclusion
Sharing code in some situations can be handy, but when you want to keep control over the scripts and how they can be executed you really need to check this option. You can take this far as setting up generic pipeline that is used within other projects.
For more information about checking out repositories: