Had a scheduled job running every 30 minutes of Azure devops, it was running fine, last scheduled build I saw was on 2019-10-02·14:00, and since then there were no changes made to azure devops or even to the repository for which the pipeline builds.
Devops is not triggering any new builds, not sure about the issue and where should I look for issues.
Tried a manual run, thinking that it could invoke the sleeping process somewhere, but it did not help
trigger:
branches:
include:
- master
schedules:
- cron: "*/30 * * * *"
displayName: Daily half-hourly build
branches:
include:
- master
always: true
....
....
For your issue ,there could be two reasons why the schedule trigger stopped scheduling new builds.
The first one : Set the schedule trigger in UI
Scheduled triggers defined using the pipeline settings UI take precedence over YAML scheduled triggers.
If your YAML pipeline has both YAML scheduled triggers and UI defined scheduled triggers, only the UI defined scheduled triggers are run. To run the YAML defined scheduled triggers in your YAML pipeline, you must remove the scheduled triggers defined in the pipeline setting UI.
The second one: Each cron schedule has a limit
Each cron schedule has a maximum of 100 pipeline runs per week.From your description: running every 30 minutes, it should exceed the limit of 100 pipelines per week. If you need more, you can split your cron schedule into multiple cron schedules that each result in 100 or less pipeline runs per week.
You can check these two points to see if this is the cause of the issue.For details please refer to this official document.
Related
I understand that regardless of commit in the VCS , if highlighted option below is selected then build would trigger as per the scheduled event. Am I correct?
What will happen when we don’t select below option? Provided in 2 scenarios with commit & with out commit?
enter image description here
You can find an explanation here: Running even when there are no code changes
By default, your pipeline does not run as scheduled if there have been
no code changes since the last successful scheduled run. For instance,
consider that you have scheduled a pipeline to run every night at
9:00pm. During the weekdays, you push various changes to your code.
The pipeline runs as per schedule. During the weekends, you do not
make any changes to your code. If there have been no code changes
since the scheduled run on Friday, then the pipeline does not run as
scheduled during the weekend.
To configure the scheduled pipeline to build only if there has been a
change since the last build, check Only schedule builds if the source
or pipeline has changed.
You configured pipeline for scheduled runs. It will run according to your schedule, irrespectively of whether commit happened or not.
You might be interested in commits-based triggers, which are Continuous Integration (CI) triggers and configured separately
Here are some examples for CI triggers in pipeline YAML file:
# specific path build
trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md
If I wanted to run a scheduled task once a month for checking for outdated dependencies but I already have a CI pipeline how can I do that? For example I have a pipeline that runs though code sniffs -> checkmarx + twistlock -> deploy to dev -> stage and whatnot. This triggers on master. I want to also include the ability to have a scheduled task of dependabot to occur once every month. How can I mix this scheduled task into an established CI pipeline? This is all contained within Azure Devops as well.
I only want to run the single task of dependabot once a month. I don't want to run the entire pipeline once a month
I suggest creating a second - entirely separate - pipeline to run dependabot once a month.
That way, you can have the appropriate triggers for the CI pipeline, and the appropriate schedule for the dependabot pipeline, with exactly the right tasks in each one and no duplication.
You can run a pipeline using both the trigger and schedules.
For example, to run a stage on the 1st day of every month at 08:00 UTC, you can use:
trigger:
- master #This is the trigger for other stages. It is not needed for the scheduled stage.
schedules:
- cron: '0 8 1 * *'
displayName: 'Deploy every 1st day of every month at 08:00Z'
branches:
include:
- master
always: true
Then, to ensure that a specific stage runs as part of the scheduled run, use the condition expression, for example:
- stage: 'Test'
displayName: 'Deploy to the test environment'
dependsOn: Dev
condition: eq(variables['Build.Reason'], 'Schedule')
Refer to this MSDocs article for more on the syntax of schedules: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/scheduled-triggers?view=azure-devops&tabs=yaml#scheduled-triggers
Azure scheduled pipeline runs for every push in master.What am I missing?Here's the yaml code:
schedules:
- cron: "0 23 * * *"
displayName: Nightly build
branches:
include:
- master
Apparently, the previous builds aren't failing.
I've already tried to remove this pipeline and create it again, but it keeps running for every push.
The scheduled runs are correct:
Ok, I think I figured this out.
Just added the following lines to the yml file and it no longer runs the scheduled pipeline on every push.
trigger: none
pr: none
Is there a way to customize the pipeline scheduling options in Azure to have it run only the second week of each month?
I know you can schedule it to run on individual days of the week, but I cannot figure out how I would do this on a monthly scale.
Can I do this if my pipeline was made as a classic/GUI based, and not
as a YAML pipeline?
In the classic pipelines, you can only set scheduled triggers for each week. As far as I know, you can not have it run only the second week of each month in the classic pipelines. However, you can set schedule triggers in yaml pipeline and use it to trigger your classic pipeline.
Here is the sample if you are going to use a YAML pipeline:
schedules:
- cron: "0 0 8-14 * *"
displayName: schedule
branches:
include:
- main
always: true
In this example:
The pipeline will be triggered from the 8th to the 14th of this
month. You need to update the date each month.
always: true means run even when there are no code changes.
Agree with iikkoo that if you want to run your pipeline by only using scheduled triggers, you must disable PR and continuous integration triggers by specifying pr: none and trigger: none in your YAML file.
You can add a build completion trigger in this yaml pipeline to trigger your classic pipeline:
Please find more detailed information about Configure schedules for pipelines in the document.
You can achive this by creating a scheduling trigger in your YAML config. Note tough, you must disabled PR and CI triggers to run your pipeline by using scheduled triggers.
You disable the trigger by setting pr: none and trigger: none. Then you define the schedule using cron syntax.
schedules:
- cron: "0 0 1/14 * *" # At 00:00 on every 14th day-of-month from 1 through 31.
displayName: Second week of each month
branches:
include:
- master
...
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/scheduled-triggers?view=azure-devops&tabs=yaml
https://github.com/atifaziz/NCrontab/wiki/Crontab-Expression
https://crontab.guru/
It doesn't seem to do so in the UI, but you can still trigger the build via an API call on your own schedule.
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/queue?view=azure-devops-rest-6.1
I have a situation where two commits were merged to master (e.g. FIRST and SECOND) very close together (seconds apart). Both triggered the build pipeline: FIRST triggered the pipeline first and SECOND triggered it second (the builds ran in parallel). For whatever reason, the build pipeline for commit SECOND finished first, and 30 seconds later the build for commit FIRST finished.
My automatic release pipeline is configured to always get the "latest" artifact from the build pipeline. The sequence of events described above caused the SECOND change to be deployed first, and then the FIRST change was deployed next (since its pipeline finished second) and stomped on the prior release, effectively deploying old bits to the service.
Is there any way to prevent this situation? Even if a build pipeline finishes second for intermittent reasons, I don't want a release to stomp over a more recent change that happened to finish earlier.
EDIT: Thank you to those who suggested/supported the idea of batching builds but that's not an option I'm looking to enable. I still want each commit to trigger its own build (to enable easier assignment of build break cause). I'm just looking for the releases to trigger in the order of commits, not the order of builds finishing.
Thanks!
You can set batch to true in triggers, so the system waits until the build is completed. Set "Batch changes while a build is in progress" option to true in Triggers for Build Pipeline at Azure DevOps or in YAML:
trigger:
batch: true
If you use Pull request, there should be no issues as new push should cancel in-progress run. Check autoCancel in PR triggers
You may need to make the pipelines to run on the same agent. So that the newest queue will wait for the previous queue to complete.
You can follow below steps to confine your pipeline to one agent.
1, Add a custom capability to the agent you want to run the pipeline(project settings->agent pools(select an agent pool)->agents(select a agent)->capabilities)
2,Add a demand to your pipeline : # this works for both microsoft-hosted agents and self-hosted agents
I tested and found microsoft-hosted agent pool doesnot support demands for custom capabilities in yaml pipeline.
Below yaml pipeline works only for self-hosted agent pool.
pool:
name: Default
demands: Tag -equals Agent1