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.
Related
For some reason, my on-premise TFS 2015 (update3) keeps removing the custom made build steps from build definitions when clicked on Edit Build Definition.
I Then need to click 'undo' to restore the removed custom build step.
Does anyone know why TFS is doing this? And also, is there any fix for this weird behaviour?
As it turns out, there was a minor configuration error in the task.json file. The person who made the build task had Deploy as the value of the visibility property, where only Build and/or Release are valid values.
I think this property somehow got mixed up with the category property - which is the build task category tab it belongs to - whereas visibility defines if the task is a valid build task for Build configurations and/or Release configurations.
I'm using TFS2013.
Do you know if there is a way to chain a gated check-in build, then a classic continuous integration build?
I currently have only one gated check-in build doing 2 actions. The problem is that the 2nd action cannot be done if the source code has not been effectively checked-in.
Any advice would be greatly appreciated...
Thanks in advance for your help.
For those who are interrested in knowing the 2 actions I try to do:
get shelved code, check code quality and compilation (classic gated check-in).
get latest source code, compile it, copy to production the compiled files that has been changed.
The comparison fails if I do it in gated check-in because the source code is retreived again on the next gated check-in -> the binary is different (contains the compilation date) -> the binary is copied again to the production folder
I found the solution.
In the xaml build file, the step getting the source code from TFS has an option named "nocioption".
By default, this value is set to true, preventing CI builds to be triggered...
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.
Here is my situation.
I setup a build definition for continuous integration using the new workflow system. Then I targeted this definition to a particular solution. I checked-in my solution many times without a problem and the builds have all passed flawlessly on the server.
This morning, I notice that it has been executed but I did not checked-in the solution. I finally discover that when a colleague checked-in another solution, it executed the definition for the solution I am working on.
I am using the original ProcessTemplate.xaml file. I only want this build definition to be executed when I check-in a particular solution or a set of solution I chose. What do I miss here?
Thanks.
There are two things you need to do,
1. Edit build defination and click on the process tab, change the 'Items to Build' to the solution that you are interested to be build as part of your build.
2. Click on the workspace tab and point it only to the branch or specifically to the folder which logically excludes the solutions that you would like to exlude from this ci build.
Make sure you carry these steps across your build definations.
HTH.
Cheers, Tarun
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.