Currently my TFS 2012 build environment features a Build Verification (BVT) build which mostly follows LabDefaultTemplate.xaml worfklow. The BVT build first queues a Continuous Build (which mostly follows the DefaultTemplate.11.xaml), waits for that build to finish, then performs the necessary tests.
Now, I would like to change this BVT build to be Gated Check-In. Which is to say, I don't want any changes to be committed until the BVT is successful. The problem seems to be queuing the Continuous build definition in such a way that it will pick up the shelf set. This logic appears to be dependent on the build being started with Reason = "CheckInShelveset". However it seems all builds queued from another build always have Reason "UserCreated". Has anyone found a way around this problem? Is it possible to chain builds together while still having Gated Check-Ins?
Related
I have created a vNext build definition in TFS 2018. I'm able to queue this
build definition many times and they were processed parallel.
This behaviour is not acceptable. If they are processed in order, I can live with it.
Does anyone know which setting I have to setup in the definition?
I'm running a tfs in following environment:
TFS 2018.2 On-Premise
4 Build-Agents with different capabilities
1 Build-Definition which fulfills the capabilities of all agents
It is planned, to have more build definitions. Today, we have only one because we are migrating our xaml-builds to vNext.
On the Triggers tab, check the "Batch Changes While Build is in Progress" option and set the number of concurrent builds to 1.
However, I would strongly recommend fixing whatever prevents your builds from running in parallel. Builds should ideally be stateless and have no impact on one another.
You can also set a custom Demand/Capability pair such that only one of your agents satisfies your build definition's requirements.
I have TFS continuous integration set up, where every check-in triggers a build. But I also want some scripts to automatically modify specific files as part of the build process. This causes a cascade of builds, because files modified by scripts cause another build to be queued. How do I enable continuous integration, but except some check-ins from triggering the build?
UPDATE Solution is: put the ***NO_CI*** into comments when checking in.
If you look at the way a Gated Build works it bypasses any configured CI by spending ##NOCI## or something similar to the checkin comment. I would think that you could do the same to bypass.
Switch to a Gated Build for one build and see the created comment tag.
I want to reorganize our build system.
Some of the builds are depended on some other builds and I want to make sure that they are not queued automatically if condition is not met(build that they depend on is not finished without errors).
Does anybody know how to do this?
We are using TFS 2012.
In TeamCity, you can create build dependencies where one build will not start until another finishes successfully. Is that possible with TFS 2012? Where can I find more information about how to set that up?
The short answer is that TFS doesn't have equivalent functionality, but you can achieve the same goals with a little work.
A common scenario I encounter is a team wants to do a build when they check-in that does some quick stuff (compile, fast unit tests), then immediately after wants to do another build that runs some slower stuff (integration tests, test deployments, etc). I do this often with my teams, and I'll setup a Gated Build that runs in say 5 mins, then have a CI build that is kicked off as soon as the Gated Build checks-in, which may take an hour to run. I like this approach as it gets the developers some feedback quickly, then more detailed feedback shortly thereafter.
Another supported scenario is having a build explicitly kickoff it's dependencies. If you look a the Lab Build Template it does exactly this, it will first kickoff the application TFS Build, and the Lab Build will sit and wait for it to finish, then the Lab Build will continue. In theory you could have Build A kickoff build B which kicks off C & D, etc.
If your needs are more complex than that (e.g. you have multiple applications that you have a build for each, then a Product that includes some applications that needs to be built after each application changes, then maybe a Product Suite build that needs to kickoff whenever a Product changes - this is the scenario I dealt with). I basically implemented a custom build dependency system to handle this. We made an XML file that described the build dependencies, then wrote a simple ISubscriber plug-in that we would deploy to TFS, and it would listen for Build Completed events then consult the dependency config and kickoff the appropriate build(s).
TFS build templates have the NoCIOption property that drives whether all gated check-in messages have ***NO_CI*** appended. This in turn optimizes away the daily continuous integration (CI) build if all the check-ins since the last CI build have been gated ones.
However, in my environment, the set of tests run during a gated check-in is much smaller than the set of tests run during a CI build, to achieve reasonable gated check-in latency, and we therefore want to run the CI build even if there have been only gated check-ins since the last CI build; this makes the prominent "NO_CI" marker as it stands quite confusing.
Furthermore, it would be nice if we had some kind of direct reference from the commit message to its respective gated check-in build number, for example from code history.
Is it possible to customize the commit message during gated check-in, so as to include the build number in it?
I have been looking at SyncWorkspace properties but saw nothing obvious.
At the moment we don't have a way to customize the commit message at this time. If you want the CI build to run after the gated checkin then you simply need to set the NoCIOption to False a CI build will be triggered after the check-in.
I don't think it is possible to get the NO CI message into a gated builds check in. Maybe you could consider using a Scheduled Build instead of a CI build to ensure your larger test set gets executed regularly.
Is it possible to customize the commit message during gated check-in, so as to include the build number in it?
No, this would not be possible. The build number is generated as part of the build script's execution; in order to display it at the point of checkin you would have to wait for the build to have started, which it may not always do immediately (e.g. if your server has to queue the build).