I have one build controller and it has 4 build agents in it. When I run more than one build at a time it queues the build. Why it doesn't run 4 builds parallel? Is there any settings that I should change?
I am running TFS 2012.
running gated checkin
it also runs all the tests after the build is done.
Thanks for the help!
This is 'by design'. From Use a gated check-in build process to validate changes
Each gated check-in build definition can have only one running build at a time.
This is necessary to preserve the logic coherence of you version control.
If this is slowing your dev organization, you have many options (some are in the doc linked):
Change from Gated to Batched gated
Have multiple Build definitions (mapped on different portions of you sources)
Minimize the checks during build
Feed more resources to the Build server
Related
Is there any options to lock TFS check-ins when the build is failing or three consequent times in Jenkins?
Not totally sure about your meaning of lock TFS check-ins. If you just want a developer checks in changes that break the build. We do not have any build in feature to support this integrate with Jenkins.
However, you can guard some or all of your code base against these problems by creating a gated check-in build definition(TFVC) or pull request(Git) through TFS own build system.
If you are using TFVC, by using Gated build, when developers try to check-in, they are prompted to build their changes. More details please take a look at our official tutorial.
If you are using Git, you could use pull request and branch policy. There is a Build validation setting in branch.
Validate code by pre-merging and building pull request changes
With using both of above method, you could only check in codes/changes when build succeed.
Exploring upgrade to on premise TFS 2017.3
We have a large project that takes about 20-30 minutes to compile. I'm planning on setting up multiple build agents on different servers to handle compilations on every check-in.
I enabled Continues Integration trigger and can run builds on all 10 agents in parallel (triggered by check-in). When I continue to check in files, the builds just put in queue waiting for agents to complete previous builds.
Selecting "Batch changes while a build is in progress" checkbox allows only one build to run even if I have 9 more agents ready for work.
How can I use all 10 agents and butch changes only when all of them are being used?
thanks.
This is the expected behavior, take a look at the behavior of "Batch changes" of Continuous Integration
Batch changes
Select this check box if you have a lot of team members uploading
changes often and you want to reduce the number of builds you are
running. If you select this option, when a build is running, the
system waits until the build is completed and then queues another
build of all changes that have not yet been built.
You can batch changes when your code is in Git in the project or on
GitHub. This option is not available if your code is in a remote Git
repo or in Subversion.
If you selected this option, then you will have to wait the build completed and queue another build. More details please take a look at the official link.
I would like to know what is the equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions.
1- Is it "Run continuous integration triggers for commited changes" in Gated trigger?
2-Or it is a "Continuous Integration trigger with batch changes checked" in build definition.
I ask this question because I was not able to launch a CI build after successfully Gated Check-in. My CI build does different steps than Gated.
I'm over TFS 2017 (15.117.27414.0).
The equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions is Continuous Integration trigger:
Enable CI trigger if you want the build to run whenever someone checks
in code.
Select Batch changes check box if you have a lot of team members
uploading changes often and you want to reduce the number of builds
you are running. If you select this option, when a build is running,
the system waits until the build is completed and then queues another
build of all changes that have not yet been built.
Select the version control paths you want to include and exclude. In
most cases, you should make sure that these filters are consistent
with your TFVC mappings on the Repository tab.
You can get more details in the link below:
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/triggers?view=vsts
We are working on TFS 2015 Update 1
The same Job is triggering CI / Gated / Scheduled Build
I want CI/Scheduled build to Publish Artifact
Unable to find a way to disable Build Step Dynamically
I am calling a Powershell Script before 'Publish Build Artifact' Step and trying to find a solution to access the next Step and Set it to 'Skip'
But I have seen even when the Drop folder is empty, the Release (CI/CD) triggers as the Gated Job is creating a Build
Is there a way to avoid Gated Job to create a Build
or to avoid Release Job to trigger in case of Gated Build
In TFS 2015 update 1 I think you're way too far behind. There are solutions for later versions. In your case, you'd need a separate Build Definition for the gated build and if my memory serves me right, you don't have the task group option yet. Task Groups were introduced in TFS 2017, they would at least allow you to share process and variables between separate build definitions.
You're on an unsupported TFS version, in any case, TFS 2015 update 1 was replaced by TFS 2015 update 3.1 any versions between TFS 2015.0 and 2015.3.1 are unsupported and TFS 2015 update 1 contains a number of XSS security vulnerabilities that were fixed in TFS 2015.3.1 as well as in TFS 2017.0.1, 2017.3.1 and 2018.1. This would be a good time to upgrade and make the jump.
In TFS 2018 this would be possible with an artefact tag filter:
Prevent Release Trigger on Gated Check-in build
One option that remains available is to turn off the CI trigger of the release workflow and then from a powershell script, conditionally trigger the release from the build.
We run an environment were multiple features are divided into branches. Those branches are configured to a channel in Octopus Deploy.
I would like to see if there is a way to check in a build definition if another build is queued for a branch.
For context - I have a Octopus Deploy step as the last step in our build definition. To deploy the app - it takes approximately 10 minutes. Our build process is also about 10 minutes (it is a big application).
When a team working on one feature checks in - we end up with 2 and 3 builds queued and waiting for each check-in and build to complete.
What I would like to do is have the deploy task run only if there is NOT another build queued for the same branch. This would ensure we don't waste 30 minutes of unnecessary deployments and only deploy the latest code.
What type of build do you use? XAML build or Vnext build. It seems that you use the CI trigger in your build definition, so it will trigger a build each time you do a check in.
VNext build:
You could select the Batch changes checkbox. According to this document,
If you select this option, when a build is running, the system waits until the build is completed and then queues another build of all changes that have not yet been built.
This will combin the changes into one build when you have a lot build queued.
XAML build:
In the build definition, you could use the Rolling builds trigger. This has the same function like the Batch changes mentioned above.
Note:
You also could use this REST API to get if there're builds of a build definition that are queued.
Http method: Get
http://servername:8080/tfs/DefaultCollection/TeamprojectName/_apis/build/builds?definitions=10&statusFilter=notStarted&api-version=2.0
It ended up being easier than I thought - but not exactly what I tried to do in the question.
The Octopus Create Release Task for TFS and VSTS has an option to "Show Deployment Progress". Checking this causes the build definition to wait - periodically receiving feedback from Octopus through the Octo.exe tool.
The deployment for this is actually a wrapper for several deployments (15 separate projects) - so it would take a long time.
Unchecking this option causes TFS to not wait - but send the create release / deploy command to Octopus.
Now this didn't solve my initial question - but Tingting0929-MFST did help me out in that I explored using the TFS Rest API. I wrote a PS script the effectively did what I asked - not deploy if there was a another build queued up for the same branch. I got it working - but it introduced a different problem in that the release notes from TFS and associated changesets / work items were getting swallowed in between releases.
In other words if three checkins came in fairly close separation, the last one would get deployed. Octopus would show only the release notes for last deployment and not the first two.
For those using Octopus Deploy in a feature branch set-up (one project deploying to multiple channels) - this is an option to get you the Continuous Deployment for each channel (branch).