I have an Azure DevOps system up and running, with triggers to run the pipeline due to PRs as well as a nightly schedule, like so:
trigger:
batch: true
branches:
include:
- main
- release/*
- pre-release/*
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
#- main
#- release/*
- pre-release/*
always: false
Is there a way to let the job know that's being called from a Schedule rather than a PR? I'd like to add another series of more rigorous tests, but just with nightlies, as part of the usual job.
Perhaps setting a variable that can be checked later in the pipeline.
You could use the Build.Reason predefined variable.
In your case checking if $(Build.Reason) equals Schedule should work.
Build.Reason. The event that caused the build to run.
Manual: A user manually queued the build.
IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.
BatchedCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected.
Schedule: Scheduled trigger.
ValidateShelvese: A user manually queued the build of a specific TFVC shelveset.
CheckInShelveset: Gated check-in trigger.
PullRequest: The build was triggered by a Git branch policy that requires a build.
ResourceTrigger: The build was triggered by a resource trigger or it was triggered by another build.
Related
trigger:
branches:
include:
- master
tags:
include:
- Showcase
pr:
branches:
include:
- master
the code above is from my yaml azure pipeline with using bitbucket repo. Anytime I do a PR in my bitbucket repository I expect build pipeline to run automatically in azure devops but it's not the case. Currently, I have to run the pipeline manually to complete PR validation. creating pipeline with the same line of code under another repo works correctly. I'm not sure what the problem is.
I created anoter dummy pipeline with a new project, the pr triggered build automatically when pr to the the master. the webhohook seems to be working fine. the trigger option doesn't override the yaml pipeline. I can't think of anything else to check.
Quite new to the CI/CD pipelines in AzDO. I was going through some official Azure Pipeline documents where I have some doubts on Schedule Triggers.
Below is a pipeline Snippet in main branch:
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
- releases/*
exclude:
- releases/ancient/*
- cron: "0 12 * * 0"
displayName: Weekly Sunday build
branches:
include:
- releases/*
always: true
The documentation says the Pipeline will run for branches "main" and "releases" at midnight if there has been some changes to those branches since the last successful scheduled run and build the "releases" branch on sunday irrespective of changes to releases branch which seems understandable.
Which means we can control other branches (e.g. releases) to build from YAML file present in another branch (e.g. main).
Again, the documentation also states, for below YAML in a release branch
# YAML file in the release branch
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
The pipeline won't build "release" branch since the branch name is missing under "branches" section. But will it build the "main" branch though since it's mentioned under "branches" section?
If no, then how can the first YAML in main branch make "releases" branches to build? Does the YAML file in main/default branch has some special capabilities?
If yes, does it really make sense to build "main" branch from release/non-main branches?
Thanks in advance.
If no, then how can the first YAML in main branch make "releases"
branches to build? Does the YAML file in main/default branch has some
special capabilities?
There's a setting for default branch in Azure Pipelines (Edit pipeline -> get sources -> Default branch for manual and scheduled builds) which tells the pipeline which branch to evaluate for scheduled runs. Yaml builds use the same scheduling that classic pipelines do and a changes to the yaml-file in that default branch are reflected in the scheduler.
Or to put it in another way, a pipeline in Azure DevOps is a separate thing from the yaml-file in repository. After creating a yaml-file in repo, you need to create a pipeline in Azure DevOps, via new pipeline -> select repo -> existing Azure Pipelines yaml file (or create a new yaml file). This step creates the actual pipeline, which has it's own configurations that are stored somewhere in Azure DevOps database. Those configurations point to the yaml file that is evaluated for pipeline runs and when the file is changed.
If you queue a pipeline manually, and select some other branch than the default, the yaml file in the branch that you selected is evaluated. Also, when evaluating branch triggers, pipeline evaluates the yaml file in the branch commit is made to. So, if you have this trigger in main branch:
trigger:
- main
- feature/*
And this in feature/foo -branch:
trigger:
- main
A commit to the feature/foo branch does not trigger the pipeline.
(Not sure if I answered the question clearly or just added some confusion, but there you go. The trigger implementation in Azure Pipelines is a bit confusing at first.)
I want to use both CI-triggers and PR build validation in Azure DevOps. The goal is that as long as no PR has been created (and published) for a feature/topic-branch, the CI triggers should ensure that the branch gets built (so that developers get early feedback). I configured the following in the Pipeline (yaml):
trigger:
branches:
include:
- chore/*
- feature/*
- fix/*
- refactor/*
paths:
include:
- frontend/*
...
This works well. I further configured PR build validation under branch policies. The problem is that two builds are triggered now: the CI build and the PR build. Since we often update PRs multiple times to fix issues found during the code review, building everything twice isn't really what we need.
Is there any way to configure that CI builds are only triggered if there's no PR build for the same push?
This is not possible. They are totally separated triggers not aware of each other.
But you can achiever your result in a slightly different way. If you have branch policy configured and you sleect there a build you can set pr: none in you yaml definiton. It will block PR build, leaving CI build as they are. And this CI build will be considered as condition for you branch policy check.
Selecting this checkbox you will get list of builds which you may select as required
My Ci trigger build
PR view:
If I understand the question correctly add:
trigger: none
In your CI pipeline. This will have the PR kick it off via branch policy. Your CD pipeline will be triggered when the merge into master happens.
If you are using the Azure DevOps Repo, then the PR build is controlled by branch policies, but the CI-trigger (in azure-pipeline.yaml) has nothing to do with this branch policy.
So if you want both build validation for PR and the CI build at the same time, then every time you push your changes to update a PR, duplicate pipeline builds would be unavoidable. It is a side-effect.
In my project I want to configure a CI and a PR build. I chose these to be separate builds, because the status badge gets dirtied if the same build is used for both CI and PR.
In my CI build I configured
trigger:
branches:
include:
- 'master'
However, when I create a PR, it gets triggered. Even in the Azure DevOps UI I can see the PR trigger as being "enabled" (see below). Note that I do not override any trigger.
You have to add pr: none in the yaml file to stop PR triggers. By default it is triggered for all branches. For CI also it is same.
Reference:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?tabs=yaml&view=azure-devops#pr-triggers
I have the following configuration in my open source project hosted on GitHub:
https://github.com/wez/wezterm/blob/master/azure-pipelines.yml#L9
schedules:
- cron: "0 0 * * *"
displayName: Daily build
always: true
branches:
include:
- master
my azure org is https://dev.azure.com/wez0788/wezterm. My project is open source and using the free tier.
The schedule doesn't appear to have any effect; no scheduled build shows up in the list of builds.
The documentation for build triggers has a troubleshooting section that doesn't have any useful information on why a scheduled build wasn't scheduled. It's not even clear if the syntax is correct as there is no UI to indicate whether the pipeline has picked up the schedule. The config is sufficient that pushes to the repo and PRs do trigger successful builds.
This question sounds similar, but with the notable difference that I've never had a single scheduled build ever run, so it's not an intermittent problem:
Azure DevOps build pipeline unreliable triggering by schedule
Someone else appears to be having the same problem and filed a GH issue over here, but since that was a doc issue tracker it got closed:
https://github.com/MicrosoftDocs/vsts-docs/issues/4589
How can I get my scheduled build to actually run?
Try to Use the following just replace double quote " with the single quote '
schedules:
- cron: '0 0 * * *'
displayName: Daily build
branches:
include:
- master
always: true
A contributor just provided a method, which I think might help you.When you first start building your pipeline with github repo, it will not trigger the schedule trigger. You need to modify the yaml file. After the modification, the schedule build should be triggered normally.
The second scenario is: there are two contributors that all use the repo on the same github to build the pipeline. One contributor's build pipeline can't trigger the schedule build, and another contributor's can trigger the schedule build normally. Their solution is: in the pipeline that can trigger the schedule build, run the schedule build again. At this time, the pipeline that can't trigger the schedule build also shows this running schedule build. After that, he can trigger the schedule build normally. So I suggest that you can try to build a pipeline with the same github repo in another project or organization. If the pipelien can trigger the schedule build normally, then you can use my method to restore the pipeline that cannot trigger the schedule build.
In addition, I think your yaml statement is no problem, I tested it with the same statement, it can trigger schedule build normally.
I suggest that you can set the trigger time to be shorter, which is convenient for testing.For example:This setting is to trigger the schedule build every minute.
I also saw that you are here to discuss with contributors with the same problem, I will also continue to pay attention to this issue.
Hope this helps.