I'm setting up Azure DevOps pipeline for CI for a .NET Core 3.0 mvc project.
I've created a new branch, DEVOPS, that I would like to store the YAML file in. The file includes a trigger for changes to the master branch:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
# other steps/tasks below...
I deleted all files except .gitignore and azure-pipelines.yml from the DEVOPS branch, committed it, and pushed it to origin (Az DevOps Repo).
I then switched to the master branch, deleted the azure-pipelines.yml file, committed, and pushed.
this did not trigger the pipeline
Then I made a change to one of the views in master, committed, and pushed.
this also did not trigger the pipeline
So, how can I configure Azure DevOps Pipelines to store the azure-pipelines.yml file in a branch other than master, and trigger on changes to master?
According to your operation steps and the YAML configuration, the build could not be triggered is reasonable.
Let's focus on the YAML configuration first. In you YAML definition, you set master as trigger branch. This means only changes occurred on master can trigger this build pipeline.
In your first action, you delete some files from DEVOPS branch. Then commit and push it into remotes/Origin. But, as what you defined in pipeline, this action could not trigger this pipeline. This is as expect.
Next, in master branch, you delete the azure-pipelines.yml file, then commit and push it. Note, at this time, the remote master branch has been sync with the local master branch. In one word, after you push to origin, no azure-pipelines.yml file exists in the master branch of Azure Devops.
BUT, whether the build can run depends on whether yml exists or not. Yeah, you have made some changes on master branch. But without yml file, the build could not be ran successfully. That's why you encountered the pipeline did not be triggered.
And, same reason for your next action.
How can I configure Azure DevOps Pipelines to store the
azure-pipelines.yml file in a branch other than master, and trigger on
changes to master?
Until now, this could not be achieve if what's your build definition type is YAML.
For the pipeline which definition type is YAML, to achieve what you expect, the yml file with the same configuration must also stored in the relevant branches which be defined in the pipeline.
Take the example you described in the question. If you only store the yml file in DEVOPS branch, no matter do any changes on master branch, it will never trigger the build.
To achieve trigger on changes to master, this yml file must also stored in master branch. So, the pre-condition of build pipeline which definition type is YAML can be triggered is, the yml file must also exists in the relevant branches if it is listed in the yml definition. This because, this build type can run based on the yml from source files.
Related
In Azure Devops, when i view a branch Repos->Branches->Select a branch i was able to click Set up build.
However, i am not able to choose an existing pipeline there.
When i select a pipeline Pipeline->Edit->Triggers i can add Branch filters aswell as path filters, however those do not take effect.
I tried to add filters for release/my-release aswell as release/* or a path-filter release.
I want to be able to start a pipeline from the Branch overview. What do i have to do?
If you're using YAML pipelines, e.g. azure-pipeline.yml, make sure this file is also available in your branch.
If the pipeline YAML was added to main after you've branched the release branches, the build will never trigger. Because the branch doesn't have the pipeline YAML .
Furthermore the triggers of the YAML should be specified in the YAML instead of Pipeline->Edit->Triggers.
Example:
trigger:
branches:
include:
- master
- release/*
Don't forget to turn off the "Override the YAML continuous integration trigger from here" Option:
Like many before me I'm struggling hard with configuring pipeline triggers in Azure DevOps.
Background:
single project in the Organization
three branches: main, Infrastructure, Application
The branches are kind of independent of each other. They are never merged into main either.
I have a pipeline which deploys two App Services. The YAML file for this pipeline is in the Infrastructure branch. The Default branch for manual and scheduled builds is set to Infrastructure.
Then I have 2 pipelines, each to deploy a different App to the App Service. The YAMLs for those pipelines are in the Application branch. The Default branch for manual and scheduled builds is set to Application.
By themselves, the pipelines work perfectly fine. However what I am trying to achieve is to trigger the App pipelines after the App Service pipeline finishes. And no matter what combination of settings I try, I can't get it to work.
This is currently how it looks like in the n-th version of the YAML:
name: 'deploy-webapp-002'
pool:
vmImage: windows-latest
resources:
pipelines:
- pipeline: 'Deploy App Services' # Internal name of the source pipeline, used elsewhere within this YAML
# e.g. to reference published artifacts
source: deploy-appservices # Azure Pipelines name of the source pipeline referenced
project: HomeLab # Required only if the source pipeline is in another project
trigger:
branches:
include:
- Infrastructure
- Application
pr: none
trigger: none
Is it even possible to do what I'm trying to do?
If yes, what settings should be specified in the Resources/Pipelines section in the YAML, and how should the Default branch for manual and scheduled builds look like for each of those pipelines?
I can reproduce the same issue when I put the YAML files separately in two branches and set the default branch.
Refer to this doc: Define a pipelines resource
When you define a resource trigger, if its pipeline resource is from the same repository (say self) as the current pipeline, triggering follows the same branch and commit on which the event is raised. But, if the pipeline resource is from a different repository, the current pipeline triggers on the default branch of the self repository.
In your case， you are using the same repo. So triggering follows the same branch and commit on which the event is raised.
To solve this issue, you need to copy the YAML file in Application Branch to Infrastructure Branch.
On the other hand, you can also try to set Build completion trigger manually on UI.
For example:
In my main branch, I have the trigger property in the azure-pipeline.yml looking at the main branch only
trigger:
- main
I then created another branch called test-pipeline and in that branch, I updated the trigger to include everything:
trigger:
- '*'
Then I built the test-pipeline branch using Azure Pipeline.
Now every time I push a commit to the test-pipeline branch, the Azure Pipeline build is triggered. How does that work? I thought Azure Pipeline only looks at the main branch for config?
How does that work? I thought Azure Pipeline only looks at the main
branch for config?
No, Azure Pipelines reads the build defintion from the commits you push, not from any specific branch.
When you create a new pipeline you select a repository and specify the name of a file which includes your build definition (usually azure-pipeline.yml)
Once the pipeline is setup Azure Pipelines will evaluate every commit that is pushed to the repository. It will look into the triggers specified in azure-pipeline.yml for that particular commit and decide whether or not to start the pipeline.
What is happening in your case is that you are pushing a commit where the trigger is set to '*', which means regardless of what branch it will trigger a build
When a pipeline is created it must be specified its file path and branch. When this pipeline runs a branch is asked again. What is the purpose of this second branch? My initial thought was that the branch where my code is located and the branch where the Yaml file is located are two different things.
However, it seems, after some issues, that when I select a branch in the Run pipeline dialog both the Yaml file and the source code are checked out from this same branch. Is it correct?
Thanks for any help.
This is the expected behavior.
In Azure Devops, the location of the Yaml file is in the branch of the repo, so thehe executed yaml file and the source branch are synchronized.
The first operation of selecting a branch is used to create the pipeline, if you run directly for the first time, you don’t need to choose the execution branch.
When you run a DevOps pipeline(select execution branch), you choose a branch to execute the pipeline. The Yaml file in that branch is the one that will be executed by default and the pipeline will checkout the source code from the same branch.
The version that gets executed will be determined by which branch you're running the pipeline for.
If you want to checkout the source files of other branches in a yaml file, you need to add an additional repo source.
For example:
resources:
repositories:
- repository: TestRepo
ref: refs/heads/branchname
type: git
name: Projectname/RepoName
stages:
- stage: deploy
jobs:
- job: test
steps:
- checkout: TestRepo
CI doesn't trigger when I change anything in my feature/* branch. I configured a YAML on Azure pipeline -
trigger:
branches:
include:
- feature/*
I also tried the other style of configuration - again unsuccessful
trigger:
- feature/*
Also tried with the complete feature name like feature/my-feature
However when I override the YAML trigger and use branch filters to point to the specific feature branch the CI works when I make changes in the branch.
I followed this official documentation
Azure Pipelines - CI Trigger on feature branch doest work with YAML
You should set the yaml file in one of branch under the feature folder.
Since you set the trigger with feature/*, but there is no branch named feature, we could not set the the yaml file in feature brance of the repo. So, we need to set the the yaml file in one of branch under the feature folder, like: feature/Test.
In this case, when I change anything in my feature/* branch, like feature/Test2, it will trigger this pipeline.
Hope this helps.
the one reason this could happen - the yaml file is not present in the feature branch. the decision to trigger the build or not comes when a commit is pushed to a branch, based on the content of the yaml file in the branch. if the file is not there, obviosuly nothing will be built.