I have a large solution. I want the ability to do gated check in on one specific file. I.e if I do check in on this specific file (that file could impact on all the solution) all the solution will build (gated check in), but if I'll do check in on another file it will do regular check in, without build.
Thank you
It is not possible to configure this out of the box. You can have Gated checkin or not configured at the solution. It will trigger based on the scope of the path configured for source.
You could create an ISubscriber event in code that checks each checkin for the offending file and kicks off a build if it is detected.
Related
I'm facing the following issue. We have a Gated Check-In setup which means changes are not directly checked-in, but a Shelveset is created and a build is run against that shelve. Only if the build is successful, the changes are checked in.
Now we setup the build definition to only map as few things as needed to build, as we want to keep the time it needs to run at a very minimum. The problem now is that if you include in your change anything that is not mapped, the build will fail in the GetSources task, as it fails to unshelve and gives a folder mapping error.
For a better understnanding, imagine the following structure:
- MyRepository
-- Sources
--- MyCodeFiles
-- Documents
--- SomeDocuments
So in the BuildDefinition we only map the Sources directory, as this contains the files we need to build. You now have to make sure to never include any change outside of Sources, for example within Documents, otherwise the Build will immediately fail.
I already searched and found the description of the unshelve command: https://learn.microsoft.com/en-us/vsts/tfvc/unshelve-command?view=vsts
According to this description it should be possible to specifiy the itemSpec that
Identifies the file or folder revisions to unshelve into the current workspace
So it seemes like the unshelve command would actually support to "partially" unshelve. However I did not see any way on how to achieve that with a vNext build, as I could not find any infos on how the GetSources task is working.
Is there something I missed or is this with the current implementation simply not possible to achieve?
I'm afraid to say you haven't missed anything, it's just not possible in the current implementation. There is a more detailed discussion here:
https://github.com/Microsoft/vsts-agent/issues/1087
I am using TFS Gated checkins. I have noticed that every time a javascript file is checked-in, it also triggers the build and it wastes a lot of time.
How can I prevent a build being triggered if a javascript file (or other similar file types) is checked in?
You have two choices:
Cloak the folder containing your JS file. If possible, set the Workspace (Source Settings in the Build Definition) to Cloak the path to the file(s) you don't want to trigger a build. This is not possible for a particular file extension though, just paths.
When you check in a JS file, add ***NO_CI*** to the end of the check in comment. This prevents a build from triggering.
Or a third choice (not a real option, but I'll put it here just for completeness): If you have permissions on the build to override the gated build, you can just tick the box and bypass the gated build.
We are having problem with 'check in'. Is there any way to check in some changes in a file and leaving behind other changes.Because we want test some changes only. I know we can exclude some changed files for check in. But is there any way to exclude some changes in single file and check in other changes in same file??
No, TFS forces all changes in a file to be checked in at the same time. There is no way to check in "only some" changes for a given file. Git does have some support for this but it is complicated. If you decide to use Git, TFS has a tool called git-tf that allows you to integrate between the two systems.
Is there a way to avoid the automated build when we checkin only js or css files?
It doesn't need to build anything, I would like to skip the build for these files.
I don't think it is possible to do what you are wanting to do- I don't think gated check-ins is that mature yet. There are quite a few outstanding enhancement requests for gated check-ins. It might be worth adding this as a request. Even cloaked folders are at the folder level and not the file level.
From MSDN:
Automatically Run Gated Check-in
Builds
A gated check-in build is run
automatically when either of the
following events occur:
A build has been defined with the Gated Check-in check box selected on
the Trigger tab of the build
definition.
Someone attempts to check in one or more changes that intersect with
any of the mapped folders in the
Workspace tab of the build definition.
Even if you add a ***NO_CI*** tag and try to checkin, it will stll fire the check to build changes.
The obvious workaround is of course to check the checkbox ignoring the need to do a build (a path I am sure you are trying to avoid).
If we take a look at the UI around editing a build definition, there aren't optional parameters for rules etcetera. All that matters is the mapped folders.
You can however set specific folders to not build by cloaking a workspace folder. However, if you do that, it will not pick up those files for builds at all. So if you had all your JS files in one folder and excluded it from the build using the cloaked approach builds would fail when you actually wanted to run the build.
I am trying to setup a gated check-in policy, but I am running into an issue with my workflow.
In the build definition menu, I select Trigger -> Gated Check-in.
This gives me the error...
"The trigger you selected in the trigger tab cannot be used with the Build Process template you specified on the process tab. (It supports the build reasons Manual, IndividualCI, BatchedCI, Scheduled, ScheduleForced, UserCreated)"
Anyone have an idea as to where I can select which build reasons it supports?
I looked through all the code in the .xaml file, but I did not see anything that stood out as being the issue.
Any help here would be greatly appreciated.
The Build Workflow has an argument called SupportedReasons that usually has a default value set. Try changing the default value of this argument.
I solved this by pasting the contents of this xaml file into an existing xaml file that I knew could be used as a Gated Check-in template.
I don't know what the difference is, but this did the trick.