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).
Related
I don't understand why can I check this two options together because this options are not similar in their behavior.
I only want to check in the changes when the build (CI) succeeds.
What I need to do?
Have a nice day.
There is no impact between CI and Gated check-in. When you select CI, it will build whenever someone checks in code, it happens after the changes have been checked in to TFS. If you select Gated check-in, it will accept check-ins only if the submitted changes merge and build successfully, which means only the build succeeded the changes can be checked in.
By default, CI builds are not run after the gated check-in process is complete and the changes are checked in. However, if you do want CI builds to run after a gated check-in, select the Run CI triggers for committed changes check box.
Detailed information you can refer to the link below:
https://learn.microsoft.com/en-us/vsts/pipelines/build/triggers?view=vsts
Since you only want to check in the changes that builds succeed, you
should only select Gated check-in.
My scenario is as follows:
Developers check-in SQL changes to directory ClientDB
A dedicated build wakes up, extracts the metadata from the checked-in files, processes it and checks the result in into a sibling directory ClientMetadata
(Developers are not allowed to check-in under ClientMetadata)
The annoying side effect, is that because the dedicated build is a CI build it wakes up twice:
Once for the changes in ClientDB, which makes it update ClientMetadata
Second time, because of its own changes in the ClientMetadata - after all, this directory appears as an Active directory in the Source Settings section of the build:
Ideally, I would like the ClientMetadata directory to be available in the workspace, but I do not want changes there to trigger the build.
Is it possible?
If the 2nd checkin from the build is done with a checkin comment that has the text ***NO_CI*** at the end, the continuous integration trigger will be suppressed.
It's a hack, but it's how gated checkins work OOTB with TFS.
What does ***NO_CI*** stand for?
Not with XAML build. It's absolutely possible in the build system introduced in TFS 2015.
When you select this trigger (CI) whenever someone checks in code, the build will run.
Actually check in files to source control during a build pipeline is not a recommended suggestion.
If you don't want to cloaked the ClientMetadata folder and still want this be pulled down on build agent during get source. Please try below workaround:
You could remove the active status for this folder and add a customize activity to only get files from TFS server path($/../../ClientMetadata) to the agent $(BuildDir).
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?
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.
Is it possible programmatically to on a Gated -Check in build in TFS 2010 to not trigger a Gated Build when checking in a specific file type, i.e. ".config"? How can I accomplish that?
Not that I know of, you can only configure the workspace mappings which controls when the build triggers. so you can include or cloak folders, but not file types.
Presumably you don't want to run the Gated Build because a config file won't affect the build. But still running the build anyways shouldn't really hurt anything, you just waste a little bit of resources on your build server.
If it's really a concern, you can customize the build template, to look at what files are in the linked changeset (using a custom activity and the TFS API probably), and if it's just config files abort the build (with a successful result).
I would go down the route of seeing what messages TFS processes when performing a gated checkin. It might be possible to some how write a TFS server side plugin to hook the event, inspect the changeset and stop the build while allowing the shelf set to commit.
You are swimming pretty far out of Microsofts swim lane on this one so I'm not sure how much work and what the side effects would be on this one.
FWIW, I would want the build to run even on a config file change because I always want to be able to deploy the latest build and see the state of my project.