On TFS 2010 we set up a build script to automatically run and deploy to our test environment no more than every 4 hours. So the trigger of the build definition is "Rolling builds - accumulate check-ins until the prior build finishes" with the check box checked for "Build no more often than every [240] minutes". The way I'm interpreting this is that if a build happens at 16:25, and there's 3 check-ins in the next 30 minutes (the last happening at 16:52), then the next build will happen at 20:25.
The issue we're seeing is that if this sequence of events happens on a Friday, then the next triggered build doesn't occur until Monday morning. We do have two build agents on their own separate virtual machine from TFS, but all machines are up and running 24/7.
There's nothing that anybody on the team is aware of that would cause this behavior, so we're at a loss for why we're seeing it. Are we simply misunderstanding the meaning of Rolling Build, or is there configuration setting we forgot to check?
EDIT: For what it's worth, the entirety of the build & deployment process takes all of 90-120 seconds. So there were not any check-ins that occurred while it was still building.
The Accumulate check-ins means that when you check-in a changeset, if there is no build of this build definition in 240 minutes, TFS will queue a build automatically. But if do not check-in a changeset, no builds will be queued.
Builds should be triggered as you wrote. 3rd build should be triggered after the first check-in after 20:25 build not before 0:25 on Saturday. :)
Try to check if changesets were not checked into the location cloaked in the build definition workspace (or checked into the location not mapped by build definition workspace).
Related
In on prem TFS 2019, I have builds that we have triggers to happen on a schedule meaning they always build at specified times during the day. What I would like to do is to not start a build if a check-in hasn't happened since the last build ran. If no check-in has happened, we really don't have a reason to build and push new code since the code hasn't changed.
By default, your pipeline does not run as scheduled if there have been no code changes since the last scheduled run.
Make sure you select Only schedule builds if the source or pipeline has changed in your Pipeline:
Or not use the always keyword in YAML build:
https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#running-even-when-there-are-no-code-changes
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.
Is it possible to set the Build.Clean control variable during a build step (Not at Queue Time), based upon the way the build is queued?
For instance, I have a build that if queued manually during the day, I want it to run Incrementally. If it runs on its schedule in the middle of the night, I want to have it do a Build.Clean, recreating the Binaries (b) folder on the build agent.
It seems like this control variable has to be set at queue time, because the build runs this operation on the Agent prior to executing any of the build steps themselves. I'm just curious if anyone else has run into this requirement before, or if it is even possible. Thank you
No, it can only be set at queue time.
In your scenario, you can create two build definitions. One for incremental build (Disable the Clean option, Clean = False), and another enable the Clean option for middle of the night build.
Reference:
Control variables
Clean the local repo on the agent--TFS 2017 RTM, TFS 2015.4
area.
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).
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