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.
Related
I have a custom TFS Build template that includes a procedure that runs a process that involves getting some data from a server and checking it into TFS before moving onto the main build process.
The steps are as follows:
Set build number
Run our custom script - get data, check into TFS
Initialize environment
Get sources from Team Foundation Version Control
Associate the changesets that occurred since the last good build
Compile, Test and Publish
The issue I appear to be having is that all change sets since the last successful build are included, except, the change set associated with the script run at step 2.
Does anyone know what could be going on here? my guess is that the logic that is looking for the change sets since last build is using a cut off that is set at the moment the build is requested (hence why the last change set is ignored) but this is just an uneducated guess.
Thanks in advance for your help.
Trying the steps below:
Edit your build definition and go to "Process" tab.
Enter "T" under "Get version" option.
Queue the build and check the result.
I would have two builds chained: the first build generates and check-in the files the second simply pulls them down.
Our builds generally have a mish mash of work items and commits associated with them and I cannot tell how TFS determines what to add. We are using TFS 2015 update 3 and TFVC.
When a build runs, it gets code from a location somewhere in the branching and folder of TFVC. Typically, something like "root\dev\src\component name" in this way we avoid getting all of the code in our repository and we have CI set up to run so that any changes in this folder will result in a CI build running.
We also run daily builds which run more tests and create a release package that is used by TFS Release Management. I would expect that any changes to code inside of the folder defined in setting up the repository for this build to be included in the associated change-sets of a build. I also expect that any changes checked-in outside of these branches would not be associated. But this is not the case. We see commits from across the entire project.
Does anyone know how this is supposed to work?
I am not sure if this should go in the question or the answer but I have found some additional information, thanks to the hints provided in the answers below.
It appears that the source settings will take the common root between mapped folders of the repository settings, so if I have 2 folders $/Relo/Dev/B1/src/Claims.Services and $/Relo/Dev/B1/src/PSScripts it will take the common root $/Relo/Dev/B1/src as the source settings and include any changes from that folder down within the build. Can anyone confirm this? Of course thats not what I want to have happen. In the History tab of the build definition if I looked at the diff I can see a field "defaultBranch" in the json which seems to be the value that controls this, is there any way to update this field directly?
TFS determines what changesets should be mapped to a build based on the Source Repository Mappings (Build vNext) in the build definition and the last successful build.
So, you will see a list of the changesets with files committed in the lowest common base of any of the mapped folders including all their descendents, since the latest successful build. Whenever you get a successful build (I hope that it happens more often than failing ones ;-)) the list will shorten and only show the last check-in.
Example mappings below will result in any changeset made to anything below $/Relo/Dev/B1/src (because it is the lowest common base):
$/Relo/Dev/B1/src/Claims.Services
$/Relo/Dev/B1/src/PSScripts
Similar it will pick up all the related work items to the above changesets.
This is what should happen. If you see something else, I would have a closer look at the Repository Mappings or Source Settings of the build definition.
#Noel - I guess you are using vNext build and not XAML builds. Or are you using a mix of XAML and vNext?
In general a scheduled TFS build will associate all changes which were not associated in the last successful run of the same build.
I suggest you check once again if the source folder locations are the same for CI build and Daily build?
I changed a TFS2013 build template and the changes don't take any effect, even if I force an exception. The changes are properly checked-in. New defined arguments are visible in the logs, but none of the newly added additional activities are executed, neither visible in the logs.
[update]
I didn't add any custom activities. I just added a new MSBuild activity just after the main build loop to build a WIX project. I also added some conditions to check whether there really is a WiX project to build or whether the given project exists.
[/update]
What could be a reason for that?
Thanks,
Juergen
In the XAML, there are 2 places where MSBuild is called, one for the "Clean" and one for the "Build".
If you add the activities to the just Clean activity, you won't see them run on the build. I usually just add my custom MSBuild stuff into both.
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.
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.