What is the difference between Individual CI and Batched CI in Azure Pipelines ?
How does it relate to the batch option of trigger in Azure Pipelines YAML ?
trigger:
batch: 'true'
branches:
include:
- main
How does it relate to the batch option of trigger in Azure Pipelines YAML ?
As the document Push trigger stated:
trigger:
batch: boolean # batch changes if true; start a new build for every push if false (default)
Explanation:
Build batching will take multiple commits and build them all at once in one batch instead of queuing each commit as a separate build which would extend the total time to build. If you are building code in Azure Pipelines and often find yourself waiting for queued builds. You may find it useful to enable build batching.
So, we could understand the state in that document now start a new build for every push if false (default). That means that if we set the value of this batch option to false, it will start a new build for every push (commit).
This is equivalent to our Batch changes while a build is in progress option in Classic modeļ¼
Related
I am using below API to get the latest deployment status(If any release going on) from 3 pipeline's before starting an deployment in each pipeline.
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=100&deploymentStatus=inProgress"
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=101&deploymentStatus=inProgress"
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=102&deploymentStatus=inProgress"
Based on count I am deciding whether the any run going on in pipeline if count > 0. I am working on logic where if any deployment going on in other pipeline then Deployment should wait for other to finish since all are deploying to same environment.
The status checking task also is in progress so it is going to infinite loop to wait if task is running. Is there any way to achieve this.
Based on your requirement, you need to check the Deployment status of the release pipeline.
To alleviate your issue, I suggest that you can add an additional stage to each release pipeline and then you can add the check deployment status in the new stage.
Refer to my steps:
Add a new stage before the deployment stage and add the status check steps.
In the Rest API, you can add the definitionEnvironmentId parameter in the URL to check the specify stage.
For example:
"https://vsrm.dev.azure.com/ABC/DEF/_apis/release/deployments?definitionId=102&deploymentStatus=inProgress&definitionEnvironmentId=xx"
In this case, you can separate the check status step and the deployment process.
For more detailed info, you can refer to this doc: Deployments - List
I am deploying a series of Cloud Build Triggers through Terraform, but I also want Terraform to trigger once every deployed Cloud Build so that it can do the initial deployment.
The Cloud Build Triggers are used to deploy Cloud Functions (and also Cloud Run and maybe Workflows). We could deploy the functions in the Terraform but we want to keep the command easy to modify so we don't want to duplicate it on both Terraform and the Cloud Build config.
It's important for the clarity and the evolutivity/maintainability of your pipeline to separate clearly the concern of each step.
You have a (set of) step to deploy the infrastructure of your project (here, your terraform)
You have a (set of) step that run process on your project (can be an Ansible script on VM, trigger Cloud Functions, Cloud Run, or a Cloud Build trigger).
I'm pretty sure that you can add this trigger in Terraform, but I strongly don't recommend you to do this.
Edit 1
I wasn't clear. You have to run your trigger by API after the terraform deployment, in your main pipeline. Then, the subsequent trigger will be done by Push to the Git repository.
I need to build a Gitlab CI pipeline manually but not using latest of my master branch, but using a specific commitID.
I have tried running pipeline manually by using variable as below and passing its value but of no use.
Input variable key: CI_COMMIT_SHA
At the time of this writing, GitLab only supports branch/tag pipelines, merge request pipelines and scheduled pipelines. You can't run a GitLab pipeline for a specific commit, since the same commit may belong to multiple branches.
To do what you want, you need to create a branch from the commit you want to run the pipeline for. Then you can run the manual pipeline on that branch.
See this answer for step-by-step instructions on how to create a branch from a commit directly in the GitLab UI.
Use the existing (created by Gitlab CI) workspace to run the .gitlab-ci.yml and from there checkout the code again in a different directory using commitID, and perform all the operations there.
In our Azure DevOps Server 2019 we want to trigger a build pipeline on completion of another build pipeline. The triggered build should use the same source branch the triggering build used.
According to the documentation this does not work with classic builds or the classic trigger definition, but in the YAML definition for the triggered build:
build.yaml:
# define triggering build as resource
resources:
pipelines:
- pipeline: ResourceName
source: TriggeringBuildPipelineName
trigger:
branches:
- '*'
# another ci build trigger
trigger:
branches:
include:
- '*'
paths:
include:
- SubFoldder
pool:
name: Default
When creating the pipeline like this, the trigger element under the pipeline resource gets underlined and the editor states that trigger is not expected inside a pipeline.
When saving the definition and trying to run it, it fails with this error:
/SubFolder/build.yaml (Line: 6, Col: 7): Unexpected value 'trigger'
(where "line 6" is the trigger line in the resources definition).
So my question is: How to correctly declare a trigger that starts a build pipeline on completion of another build pipeline, using the same source branch? Since the linked documentation actually explains this, the question rather is: what did I miss, why is trigger unexpected at this point?
Update: I just found this. So it seems one of the main features that they promised to have and documented as working, one of the main features we switched to DevOps for, is not even implemented, yet. :(
Updates are made every few weeks to the cloud-hosted version, Azure DevOps Services. These updates are then rolled up and made available through quarterly updates to the on-premises Azure DevOps Server and TFS.So, all features are release in Azure DevOps Service first.
A timeline of feature released and those planned in the feature release can be found at here-- Azure DevOps Feature Timeline
You could choose to directly use cloud version Azure DevOps Service instead or monitor latest update on above Feature Timeline with Azure DevOps Server. Sorry for any inconvenience.
VSTS allows you to select which branches automatically trigger a CI build by specifying a branch pattern.
However, my unit tests are using a real database which causes a problem when more than one build triggers e.g. master and feature-123 as they will clash on the database tests.
Is there a way of specifying that only one such build should be run at at time; I don't want to go away from executing tests against a real database as there are significant differences between an in-memory database and SQL Azure.
VSTS already serialize builds which are triggered by the same CI build.
Even CI build can be triggered by multiple branches, but for a certain time, only one build is running by default (unless you use pipelines to run builds concurrently).
Such as if both master branch and feature-123 branch are pushed to remote repo at the time time, the CI build definition will trriger two builds serially (not concurrently).
If you are using pipeline and need to run the triggered builds serially, you should make sure only one agent is used for the CI builds. You can use the way below:
In your CI build definition -> Options Tab -> add demands to specify which agent you want to use for the CI build.
Assume in default agent pool, there are three agents with the agent name: default1, default2 and default3.
If you need to specify default2 agent to run the CI build, then you can add the demands as below:
Now even multiple branches have been pushed at the same time, they will be triggered one by one since only one agent is available for the CI build.
If you use a YAML pipeline, you can use a deployment job in stead of a regular job.
With a deployment job you select a named Environment you want to deploy to.
You can configure the Environment in azure devops under Pipelines->Environments and you can choose to add an Exclusive Lock.
Then only one run can use the environment at a time and this serializes your runs.
Unfortunately, if you have multiple runs waiting for the environment (because one run currently has it locked), when the environment becomes unlocked only the latest run will continue. All the others waiting for the lock will be cancelled.
If you want to do it via .yml or .yaml file you can do following
- phase: Build
queue:
name: <Agent pool name>
demands:
- agent.name -equals <agent name from agent pool>
steps:
- task: <taskname>
displayName: 'some display name'
inputs:
value: '<input variable based on type of task'
variableName: '<input variable name>'