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

How to Automatically deploy Configuration Files with Azure DevOps CD pipelines

Introduction Part of the CI/CD Automation is to add environment-related configuration files through deployment automatically, rather than manually uploading them. This will provide less human error and more security by splitting the developer's responsibility of knowing the environment configuration or editing it, as to be handled by Operation side. We will take an example of CI for DotNet Core 6 WebApi project, and on that project, we need to copy the related appsetting.json to its environment. Pre-Requested Knowledge: To benefit from this article you need to be familiar with the following:  Azure DevOps. the Concept of CI/CD. Azure CI/CD Pipelines. DotNet Core Web Api Deployment (or similar). Adding From Source Code Branch In some cases, we will have configuration files included in our source code, for example, in
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 simple solution that manages the cust
Read more

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