My TFS repo has the following structure:
Project
- Dev
- 1.0.0_Branch1
- 1.1.0_Branch2
- N.0.0_BranchN
The branches are actual branches in TFS.
I have an automated CI build set up for this project on a TFS server. The issue I am having is that I need the build name in TFS to use the name of the branch.
I have tried a number of the build definition variables listed here , for examle $(SourceBranchName) and and $(Build.SourceBranchName) but all of these are instead using the name of the Project (Project in this example).
I would like the build to be named along the lines of 1.0.0_Branch1.1 with the last number being the revision.
The reason I would like to do this is so that when I generate Nuget packages at the end of the build, they can be versioned using the version of the branch that is being built. Currently they are being versioned using the date which means that the highest version is only ever the most recently built, which may not be the case in practice. I don't want to have to manually set the versions each time.
All assemblies that are being built are correctly versioned to match the branch that they are within.
Is there a way to achieve this?
For build definitions, $(SourceBranchName) can be used in the build number format:
example build:
The environment variable is BUILD_SOURCEBRANCHNAME so it will be available as $(BUILD_SOURCEBRANCHNAME) in msbuild.
The list of available variables is found at: https://www.visualstudio.com/en-us/docs/build/define/variables#predefined-variables
This could be caused by the "Mappings" setting you configured under "Repository" tab in your build definition. When you build with TFVC repository, the BUILD_SOURCEBRANCHNAME variable is filled with the last path segment in the root server path of the workspace. So I'm wondering that the mapped server path in your build definition is "$/Project" rather than "$/Project/Dev/1.0.0_Branch1".
TFVC repo branch: The last path segment in the root server path for
the workspace. For example in $/teamproject/main this value is main.
Refer to this link for details: Predefined Variables.
Related
I'm trying to deploy a Continuous Integration server where I work.
We used TFVC with the branch to release strategy, but we are having difficulty with something that should be trivial.
We only need the build on the branch that was checked in.
Is it possible to do this without having to change the build definition every time a new branch is created?
I do not want to map the entire folder structure of the repository. Imagine having 10 branches and every check-in, build all? Does not make sense!
Anyone have any idea how to do it?
The CI build for TFVC can’t map and just build target branch like build for Git.
There are some workarounds:
Clone a build definition and change source mapping, Path filters of triggers for each branch.
Add a PowerShell step/task to get recent check-in change by calling get changesets Rest API, then store the related solution/project files in a variable by using Logging Commands, then build these solutions/projects
Build 2015 vNext Triggers - Continuous Integration, trigger on changes in any path defined in repository
If i define a vNext Build in the on-Promise Version and i want it to run as a CI Build (Continuous Integration) i have to define the whole list in the trigger section, which i already defined in the repository, again.
i want my ci-builds to run, if changes happen in any of the tfs paths defined in the repository. But for achieving that, i always have to copy paste everything from repository to the trigger - ci part.
Its annoying and time consuming especially because the ci trigger definition also doesn't get cloned if you want to define a new build out of an existing one.
May anyone have come along with that also and may have something in mind which could make it easier and less time consuming?
There is no such feature or setting by default, as Repository and CI filter are used for different purpose:
Repository specifies which files will be downloaded from your remote
repository into a local sources directory by build agent at the
beginning of the build process.
CI filter selects the version control paths you want to include and
exclude.
An idea to have CI filter the same as Repository mapping by default has been submitted at the Visual Studio User Voice, Microsoft Product Team will evaluate it carefully.
I have an instance of TFS 2015 with vNext builds working on my DEV branch.
I cloned a working build definition and set the Maps and solution file to the corresponding paths on the Main branch. On the Main branch they fail with the error message: "Could not find a part of the path 'C:\agent4_work\5f9b9727\myTfsProjectName'." This path is not even being created in the _work directory like is when I use the paths for the Dev branch.
Notable similarities between the two builds:
The build steps being used in both cases are the NuGet Installer and Visual Studio Build steps.
Same code exists in both branches.
Notable differences:
Main is the parent branch of DEV
Main has an added permission group to deny certain users from checking in.
My TFS service account is not a member of this group so I don't that applies.
Note: If I change the clone to point to DEV, it doesn't fail.
Can anyone tell me how to solve this mystery? Thanks.
Edit:
I found another difference the working branch has that the Main branch doesn't.
I don't remember adding the Project Build Service to the Dev branch. I also don't know why Main did not have this security setting. After I added the same security credential to Main, builds on Main started working. This raises another question: Does one need to add the Project Build Service to every branch as a second step in order to perform TFS builds?
Usually, the Build service account should be created and added to code repository automatically when the project is created and it will be inherited in every child folders. So the user does not need to add it to other branches/folders manually. For your case, I'm not sure if the user is removed unexpectedly or any other things happen.
Have you set "Items To Build" to correct path?
In Build Definition->Process-Items to build
screenshot from Build Definition
I am not a developer nor am I the Application Lifecycle Manager. I pull the latest builds from TFS Build Server along with the latest code and I import them in AppScan source for analysis (security tool). Against each security findings there is a class name within which the findings were found along with the directory where the class is located.
Builds are created automatically during a certain time of the day. As mentioned earlier the directory names change every time after a new build and a new number (highlighted below) is introduced. It is not sequential, does anyone know of TFS build server assigns these numbers.
C:\Builds**12**\Development
C:\Builds**14**\Development
C:\Builds**13**\Development
C:\Builds**15**\Development
TFS will create folders based on the following.
DriveLetter\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
so if you have 1 controller with 4 agents on a clean install you would get
Drive:\Builds\1\$(BuildDefinitionPath)
Drive:\Builds\2\$(BuildDefinitionPath)
Drive:\Builds\3\$(BuildDefinitionPath)
Drive:\Builds\4\$(BuildDefinitionPath)
Your Build definition is the name of the build definition and then each subsequent build is stored underneath, with each individual build getting its own folder.
these settings are available on the Build Agent properties screen.
These are transient files and you cant rely on them being there. They are only used as part of the build. You would be better doing a "Get" from TFS at the appropriate Changeset number for the build and using the binaries from the drop folder.
If you follow some of MS's recommended branching strategies you can easily end up with a project structure such as:
$PROJECT\
DEV\
MyProject
STAGE\
MyProject
PROD\
MyProject
Now let's say I have three different build definitions. One each for DEV, STAGE, and PROD. This should be common considering that the build definition will define the exact solutions to build.
If I turn on CI for each of them, STAGE will be built even though the checkin occurred in DEV...
Now my question. How can I limit the build definition to execute only when a check in occurs in either a path or a solution that is part of the build definition?
When defining the working folder configuration screen - only have it start at the root of the branch you want to build.
For example, your DEV branch would be configured so that $/TEAMPROJECT/DEV/MyProject was mapped to $(SourceDir) rather than the default mapping which would have been set to just $/TEAMROJECT.
FYI - Personally, I only have CI Builds on Dev branches and queue manual builds for a push to QA. I also normally don't do a re-build for production but just push the build binaries that were QA'd. I also keep by build configuration folder inside the branch i.e. $/TEAMPROJECT/DEV/TeamBuild rather than the default $/TEAMPROJECT/TeamBuildTypes and therefore changes to the build configuration are also pushed up through the branches. That said, you have to stick with the default if you wanted the build configuration to be visible to VS2005 clients.
Hope that helps,
Martin.