Is there a way to change the timeout for build pipeline, currently the pipeline time's out after 60 mintues. I want to reduce it to 30 minutes.
I looked at all the organization settings and project settings, but not able to find anything on the UI
Or else can it be set from YAML?
For a YAML pipeline the documentation says you can write
jobs:
- job: Test
timeoutInMinutes: 10 # how long to run the job before automatically cancelling
cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them
timeoutInMinutes: 0 should also work for individual tasks, and 0 means max value (infinite for self-hosted agents).
azure devops build pipeline reduce the timeout to 30 minutes
Edit the pipeline you want to modify. On the Options tab, there is an option Build job timeout in minutes, which you can set the Build job timeout, the default value is 60 minutes.
This timeout are including all tasks in your build pipeline rather than a particular job, if one of your build step out of time. Then the whole build definition will be canceled by the server. Certainly, the whole build fails and all subsequent steps are aborted.
As per documentation ,
On the Options tab you can specify default values for all jobs in the
pipeline. If you specify a non-zero value for the job timeout, then it
overrides any value that is specified in the pipeline options. If you
specify a zero value, then the timeout value from the pipeline options
is used. If the pipeline value is also set to zero, then there is no
timeout.
more on,
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=classic&viewFallbackFrom=vsts#timeouts
Related
My requirement is, i have to run azure pipeline after 15days of the trigger. I have 2 pipelines where first pipeline will execute and after that pipeline is started, the second pipeline should trigger after 15days only. How can i do that? Can we tweak cron to do this?
I tried using cron but there is no way to set this up.
There is no out-of-the-box type of trigger to achieve it according to Microsoft document at present.
But you can make the job depends on an agentless job that includes delay task to pause execution of the pipeline for a fixed delay time. Please refer to doc:Delay task
for example:
1 add a delay task in an agentless job and configure delay time 21600 minutes(15 days)
2 make the job depend on agentless job
3 set build trigger
Note :set build job timeout to 0
I have a complex devops build script in yaml. Is there some way that if a given step takes too much time the process is killed (or some task is executes which kills certain processed).
This is would be useful in our case where we have large tests suites in several DLLs. I am seeing often that some tests fail and after devops hangs. I would like to kill the testrunner and other processes which may be hanging with (and also without) a timeout.
Is this possible on devops?
You can specify timeoutInMinutes and cancelTimeoutInMinutes for the job:
jobs:
- job: Test
timeoutInMinutes: 10 # how long to run the job before automatically cancelling
cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them
More information: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml#timeouts
We have dozen of multistage YAML pipelines responsible for deploying microservices. Each of them has a stage A which targets EnvA environment with an Exclusive Lock enabled.
The Exclusive lock guarantees us two things:
the latest run only from each of the pipeline can be executed (batch behavior)
only one run across all of the pipelines can use the EnvA environment at the same time, other are waiting when the environment will be free
The environment has also an Azure Function check which verifies the time of the day and allows or forbids deployment. It means that for example, the Azure Function allows deployment between 8.00 - 10.00 and 14:00 - 16:00.
The only documentation about this feature is
The exclusive lock check allows only a single run from the pipeline to proceed. All stages in all runs of that pipeline which use the resource are paused. When the stage using the lock completes, then another stage can proceed to use the resource. Also, only one stage will be allowed to continue. Any other stages which tried to take the lock will be cancelled.
Exclusive lock
There is not any information on how the timeout works for the Exclusive lock:
Is it the max time the stage could occupy the EnvA environment and for example if the timeout is set for 10 minutes but the stage's job takes 20mins then after 10 minutes the lock is released and the next pipeline can use this environment even the previous one is still in progress?
When the timeout starts, when a particular pipeline's stage locked the environment? Or when the pipeline stage starts and is waiting in a queue for pipeline A, B, C, D to release the EnvA environment?
What are the states of the Exclusive lock, acquired, obtained? How to track the queue of the pipelines which waits for other pipelines to release the lock?
Is it the max time the stage could occupy the EnvA environment and for example if the timeout is set for 10 minutes but the stage's job takes 20mins then after 10 minutes the lock is released and the next pipeline can use this environment even the previous one is still in progress?
If you configure the Exclusive lock and set the timeout value to 10 minutes, it will not release the lock after 10 minutes, It will cause the next pipeline to fail after 10 minutes.
For example, we set the timeout value to 10 minutes, add the env to pipeline A and pipeline B, run the pipeline A which contain the power shell script Start-Sleep -Seconds 1000, then run pipeline B.
Result:
The pipeline B will fail after 10 minutes.
In addition, if we set the timeout value to 10 days. The pipeline B will continue check. When the pipeline A using the lock complete, the pipeline B will continue to run.
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
I'm running e2e tests in a stage in my Bluemix DevOps pipeline but it is exceeding the 60 minutes limit:
The execution exceeded the time limit of 60 minutes.
One possible solution is to split up your execution.
Finished: ERRORED
Is there a way of increasing the stage timeout? I do not want to split my tests across different stages.
No, it is not possible to change the timeout for a running build. Instead of using different stages, you could try using multiple test jobs on your one stage as each job has the timeout of 60 minutes. One possible way to break it down could be one job per test suite.