Build Multiple Repositories with Single Pipeline Introduction in Azure DevOps

 This section discusses how to build multiple Repositories with a single pipeline. this could be needed when the feature you deliver may affect multiple code repositories and you need to ensure that all build together.


The resources Section on the Pipeline

To tell the pipeline about the other repositories that need to be built, you need to add the resources section before starting steps or jobs sections. let's see the resources section structure:

resources:
  repositories:
  - repository: <RepositoryAliasName>
    type: git
    name: <AzureDevOps-ProjectName>/<RepositoryName>
    ref: <BranchName>

The resources section contain sub-section repositories, which contains one or multiple repository definitions.

For each repository we need to define the following:

  • repository the value will be an alias name for the repository, this name will be used on another pipeline step checkout.
  • type: define where the repository is:
    • git: if the repository is a git repository in the same Azure DevOps server and on the same organization as the pipeline.
    • For more types check this document.
  • name: it’s a combination of the project name on Azure DevOps and the repository name.
  • ref: the branch that will check the code from.


The checkout Section in the Pipeline

After defining the values of resources.repositories, you have to check out the code, we will do that inside the steps section:

##
steps:
- checkout: <RepositoryAliasName>
##

The checkout key takes one value which is the alias name that we gave to the repository on resources.repositories.

Notes That:

  • you have to define and check even the repository that contains the pipeline.

  • The first time you run the pipeline after adding the repository and checkout, it will ask for giving permission to access the branch.

    just click View and then Permit for more information about pipeline limit job Authorization check the following link.pipeline-need-permission-first-checkout-branch


Archive the build Results

After the checkout completed, the build task can start, and the checkout step will download the source code in a folder with the same name as the repository name. Therefore, the build will be done in that folder.

You can build multiple repositories in one step if both repositories use the same framework.

After the build, you can copy or archive the build result to Artifact

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '<RepositoryName>/<BuildingPath>'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/<ProjectName>.$(Build.BuildNumber).zip'
    replaceExistingArchive: true

Here we did a step for archiving one of the projects, as you notice, the Repository Name must be added as a part of the building result path.

The same can be for the copy task.

Comments

Post a Comment

Popular posts from this blog

Adapting a New Technology: A General Guide to keep Your Systems up-to-date

Image
Special Thanks to [Mohamed Othman](https://www.linkedin.com/in/mohammad-othman-55351b20b/) for his help in editing this blog. ## Introduction If you are generally working in the technology sector and specifically in the software industry, you will be under stress by the number of new things that are coming up every day. New stuff can be a new integration technology, a new framework, a language version upgrade, or even a new library that helps you to do specific tasks in your code. In this article we will refer to those as: "new Tech". And if you are like me, you will feel messed up if you don't know or know how to use the new trend! So here, I will list some tips and tricks, along with best practices for keeping your projects up-to-date. **Note**: the tips in this article for when and how to implement the new technology in your daily working projects are not concerned about keeping your knowledge up to date, knowing things and doing them are two different t...
Read more

Practices for Clean & Secure Code Repositories

Your code repository is your most valuable asset, it represents the timeline and story behind what you’re building. It serves as your backup in case something goes wrong, which is why it’s essential to keep it as clean and organized as possible. Here are some best practices you can follow to achieve that for both private and public repos: ## The main contains the latest code always I’m a fan of using GitHub Flow for code management. Unlike the traditional Git Flow, where you have multiple main branches (one branch per environment), GitHub Flow has only one main branch. Other branches are used exclusively for feature development. The main branch always contains the latest code merged from feature branches. However, this doesn’t necessarily mean the code is already in production; it simply reflects the most up-to-date work from the developers. By following this approach, you ensure a single source of truth for the latest code and a single branch to deploy from. Even fixes ...
Read more

Adding Multiple DB Contexts in your DotNet Project

Introduction  In this article we will discuss adding multiple DB contexts to our DotNet projects, we will use EF core as our ORM to make a "Code First Database" approach.  In this article example, we will use DotNet 7 connecting to SQL Server through EF Core 7, all of this will be in a web API project to see how to define those DB contexts as services in program.cs  file.  You can download the example source code from here .  Why would we need multiple DB Contexts in our Solution?  There are two situations where you need multiple DB Context in your project or Solution:  We have a single database but need multiple  schemas in our database, and each scheme will have a group of entities.  We have Multiple databases and our project needs to connect them to do its operations.  We will take the first situation as our code example. Creating Our models Let's assume we have a si...
Read more