Azure Devops - How to force a CI to be triggered on new branch, or work with Release branches?

3
votes

It used to be the case that Azure DevOps would run a new CI build when you pushed a new branch to Origin. My company relied on this, as we would issue releases by creating a release/* branch off of develop which would trigger a build and a subsequent release into our testing environment. If everything passed UAT/QA, we would deploy the that same build into production.

Our Build Pipelines are both Classic UI and have two Branch filters, develop and release/*. The one product in question has two build pipelines - one for the Webjob and one for the API, and as such each pipeline has a Path filter (to, or not to, include the Webjob folder). Creating a release/* branch does not trigger either CI pipeline.

Our Release Pipeline looks like the following, where DEV is triggerd on artifacts produced from develop and TEST->PROD is triggered on artifacts built from release/* - Azure Release pipeline

This allows us to have a release environment where we iteratively make changes to get it ready, while we simultaneously make changes to develop for the next release. This is a common Gitflow model.

The Problem

Now that Azure no longer triggers a build on branch creation, I'm forced to manually run a build on Release in order to trigger the build and subsequent TEST deployment depicted in the image above.

What can I do to have automated builds and deployments in Azure while maintaining Gitflow?

3
azureazure-devopsazure-pipelinesazure-pipelines-release-pipeline
What form is your build pipeline, yaml or classic? I have test the branch creation, which works fine on triggers a build when branch creating. Would please share Branch filters for your trigger on your build pipeline? And I haven't seen any official statement stating that this feature has changed. If you have, can you share it? – Leo Liu-MSFT
Hey Leo! Thank you for the response. I will update my original post with the build pipeline. Here is the link describing the change.. Of note: I specifically create a Release branch off of Develop and expect that, without any changes (literally just a branch creation and subsequent push to origin), I would like that branch to receive a CI build. – Stephen Vernyi
Wow @StephenVernyi I worked with a Microsoft Engineer on the FastTrac team and I mentioned CI wasn't triggered from creating a new branch and he even said it should work. Never got this answer... as its clearly documented in that update. Have you found a workaround? I'm dealing with the same problem. – Matt Newbill
@MattNewbill Hey! Unfortunately, to this day I am still stuck manually running my builds in order to get the release/* branch to trigger a TEST Release. – Stephen Vernyi
Hey @StephenVernyi, I have a 2 sorta workarounds... 1) You can update the version within the pipeline that creates your release branch, the commit triggers the CI build 2) You can try utilizing a Marketplace task called Trigger Build Task - within this you can trigger as many builds as you want, however in order for it to be on the right branch, there are complexities though,if you're interested in hearing more I can write an answer below, but comments are limited to like 300 characters – Matt Newbill

3 Answers

1
votes

I was also stuck not knowing why my TEST build wouldn't trigger. This post helped explain why. More searching found the way to resolve it. Simple as removing any path checks from your TEST build.

From the linked documentation:

If your pipeline has path filters, it will be triggered only if the new branch has changes to files that match that path filter. If your pipeline does not have path filters, it will be triggered even if there are no changes in the new branch.

See: Behavior of triggers when new branches are created

-1
votes

Not sure if you are using YAML or not but using the GUI you can add a 'path' filter for Continuous Integration and set the build to run anytime a path contains 'release'.

enter image description here

-2
votes

YAML pipelines are configured by default with a CI trigger on all branches.

YAML pipelines are configured by default with a CI trigger on all branches. When defining pipelines using YAML and defining a repository resource (repo for shorthand). A new pipeline run gets triggered when a commit has occurred. You can further configure the trigger to ONLY act on certain branches.

See:

Example (All branches by default):

resources:
- repo: self
  clean: true

pool:
  vmImage: 'ubuntu-20.04'
    
steps:

- task: CMake@1
  displayName: 'Generate Makefile'
  inputs:
    workingDirectory: $(Build.SourcesDirectory)
    cmakeArgs: '-B$(Agent.BuildDirectory) -H.'

- task: Bash@3
  displayName: 'Build project'
  inputs:
    workingDirectory: $(Agent.BuildDirectory)
    targetType: 'inline'
    script: 'make -j4'

Limit to release branches (add trigger to repository resource):

trigger:              # Optional; Triggers are enabled by default
      branches:       # branch conditions to filter the events, optional; Defaults to all branches.
        include:
        - release/*