Skip to content

Latest commit

 

History

History
177 lines (102 loc) · 7.57 KB

ci-build-git.md

File metadata and controls

177 lines (102 loc) · 7.57 KB
Raw
title description ms.topic ms.assetid ms.date monikerRange recommendations
Building multiple branches
Build multiple branches with Azure Pipelines
how-to
E9684A1D-8D2B-4D5E-808A-D3677D314DB6
06/14/2023
<= azure-devops
true

Build multiple branches in Azure Pipelines

[!INCLUDE version-lt-eq-azure-devops]

Using Azure Pipelines, you can create triggers to build your project on every new commit and pull request to your repository. In this article, you will learn how to enable continuous integration and set up multiple branch builds for your repository.

Prerequisites

Enable CI trigger for a topic branch

When working with Git, it is a common practice to create temporary branches from the main branch to facilitate a streamlined workflow. These branches, often referred to as topic or feature branches, serve the purpose of isolating your work. Within this workflow, you create a branch dedicated to a specific feature or bug fix, and once completed, you merge the code back into the main branch before deleting the topic branch.

YAML

::: moniker range=">=azure-devops-2020"

If no trigger is explicitly specified in your YAML file, any changes made to any branch will trigger a run. To add triggers for both the main branch and any feature/ branches, include the following snippet in your YAML file. This will ensure that any modifications made to these branches will automatically trigger a pipeline run.

trigger:
- main
- feature/*

::: moniker-end

::: moniker range="< azure-devops" YAML builds are not yet available on TFS. ::: moniker-end

Classic

  1. Sign in to your Azure DevOps organization, and then navigate to your project.

  2. Select Pipelines, and then select your classic pipeline. Select Edit to modify your pipeline.

  3. Select Triggers and then check the Enable continuous integration checkbox.

  4. Under Path filters dropdown, type feature/* in the Path specification text box to trigger on any changes to all feature branches.

  5. Select the Save & queue menu and then Select Save.

:::image type="content" source="./media/classic-continuous-integration-trigger.png" alt-text="A screenshot showing how to add a CI trigger to a classic pipeline.":::

Customize build tasks based on the branch being built

The main branch is usually responsible for generating deployable artifacts, such as binaries. For short-lived feature branches, there is no need to invest time in creating and storing these artifacts. In Azure Pipelines, you can implement custom conditions to ensure that specific tasks are executed only on the main branch.

YAML

Edit the azure-pipelines.yml file in your main branch, and add a condition to your desired task. For example, the following snippet adds a condition to the publish pipeline artifacts task.

::: moniker range=">=azure-devops-2020"

- task: PublishPipelineArtifact@1
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

::: moniker-end

::: moniker range="< azure-devops"

YAML builds are not yet available on TFS.

::: moniker-end

Classic

The following example adds a custom condition to the publish build artifacts task.

  1. Select the Control Options section, and then check the Enabled checkbox.

  2. Select the Run this task dropdown menu, and then select Custom conditions.

  3. Enter the following snippet in the Custom condition text box. This task will only execute if you're building the main branch.

    and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

  4. Select Save & queue when you're done.

:::image type="content" source="media/ci-build-git/customconditions.png" alt-text="A screenshot showing how to add a custom condition to the publish build artifacts task.":::

Validate pull requests

To ensure branch protection, you can utilize policies that mandate successful builds prior to merging pull requests. Using Azure Pipelines, you have the flexibility to configure the requirement of a new successful build for merging changes into crucial branches like the main branch.

GitHub repository

YAML

::: moniker range=">=azure-devops-2020"

If you don't explicitly define pr triggers in your YAML file, pull request builds will be enabled by default for all branches. However, you have the flexibility to specify the target branches for your pull request builds. As an example, if you want to run the build exclusively for pull requests targeting the main branch and branches starting with feature/, you can specify the following configuration:

pr:
- main
- feature/*

::: moniker-end

::: moniker range="< azure-devops"

YAML builds are not yet available on TFS.

::: moniker-end

Classic

  1. Sign in to your Azure DevOps organization, and then navigate to your project.

  2. Select Pipelines, and then select your classic pipeline. Select Edit to modify your pipeline.

  3. Select Triggers, and then select the Pull request validation. Check the Enable pull request validation checkbox and ensure you have the main branch in the Branch filters.

  4. Select Save & queue when you're done, and then select Save one more time.

:::image type="content" source="media/classic-pull-request-validation.png" alt-text="A screenshot showing how to enable pull request validation.":::

Azure Repos repository

  1. Sign in to your Azure DevOps organization, and then navigate to your project.

  2. Select Repos and then select Branches.

  3. Select the ellipsis icon to the right of your branch name, and then select Branch policies.

  4. Under the Build validation menu, select the + sign to add a build policy.

  5. Select your Build pipeline from the dropdown menu and make sure that Trigger is set to automatic and the Policy requirement is set to required.

  6. Enter a descriptive Display name to describe the policy.

  7. Select Save to create and enable the policy. Select Save changes at the top left of your screen to save your changes.

:::image type="content" source="media/add-build-policy.png" alt-text="A screenshot showing how to add a new build policy.":::

  1. To test the policy navigate to Repos > Pull requests in the Azure DevOps portal.

  2. Select New pull request and make sure that your topic branch is set to merge into your main branch, and then Select Create.

  3. On your screen, you can see the currently executing policy.

  4. Select the policy name to examine the build. If the build succeeds your pull request will be merged. If the build fails the merge will be blocked.

Note

Azure Pipelines no longer supports per-pipeline retention policies. We recommend using project-level retention rules.

Related articles