I've seen several mentions of variables holding the TFS branch name, pulled from the last directory in the Source Settings path of the build definition, but I've not gotten any to work in TFS 2013. Is there a variable that will populate in my MSBuild script(triggered from the build definition) in TFS 2013?
This is what I've tried with no luck, all are blank:
<Message Text="SourceBranchName: $(SourceBranchName)" />
<Message Text="Build.SourceBranch: %(Build.SourceBranch)" />
<Message Text="BranchName: $(BranchName)" />
<Message Text="Build.SourceBranchName: %(Build.SourceBranchName)" />
<Message Text="BUILD_SOURCEBRANCHNAME: $(BUILD_SOURCEBRANCHNAME)" />
Environment variable data in MSBuild script with TFS2013 do not use that kind of format.
It should be TF_BUILD_XXX such as
TF_BUILD_BUILDDIRECTORY: The build agent working directory. For example: C:\Build\BuildBot3\CoolApp\CIBuild.
The official tutorial with XAML build in TFS2013, you could refer this link-- Team Foundation Build environment variables.
As you can see, we do not have an Environment variable related to branch name used in build.
For a workaround, you could use client API to fetch similar info.
There is a property within an IBuildDetail object called SourceGetVersion. When a build definition is manually executed or triggered using the default branch defined in the build definition, then this property simply returns 'T', but if the build definition was triggered by a commit to a monitored branch, then this property is set to the branch name.
Simply parse the value of this property and you should be able to determine exactly which branch triggered the build definition. Or you could also use
TF_BUILD_SOURCEGETVERSION: The version (TFVC changeset or Git commit) being built.
You're looking at the documentation for the build system introduced in TFS 2015. TFS 2013 only supported XAML build, which is deprecated and thus increasingly difficult to find documentation about.
There is documentation available, however.
The problem here is that you're looking for a variable that doesn't exist in TFS 2013. The best you can do is TF_BUILD_SOURCEGETVERSION, which will be either the TFVC changeset or the Git commit hash being built.
Related
I am attempting to create a build definition in TFS 2015 that is triggered after a Pull Request is created. It is triggered as part of a Branch Policy (Automatically Build Pull Requests).
I have a Command Line build task that uses the following:
Tool: C:\Path\To\My.exe
Arguments: $(System.PullRequest.PullRequestId)
My .exe creates folders and files depending on the PR ID from TFS. One of the folders is a direct copy of the PR ID (so the folder would be named "25" for PR 25).
Here is what my folder name looks like after my build runs successfully:
$(System.PullRequest.PullRequestId)
As you can see, it is not evaluating the ID at build time.
How do I pass the PR ID to a command line executable build task using TFS 2015?
It turns out that the $(System.PullRequest.PullRequestId) variable is not supported in TFS 2015.
I upgraded our TFS installation to Azure DevOps Server 2019 and it fixed the issue.
I found a List of TFS Environment Variables on the web that helped me with my answer.
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
When we do a TFS Build, can we alter the build output so that the output is limited to only the changes so that deployment payload is reduced ? Example:
When I build a solution, I should only get the changed dlls not all (which includes Microsoft and other 3rd party dlls which are never changed.
Configure CI solution in TFS 2015, and unchecked clean options, Since TFS 2015/2017 always delivered all files - changed and unchanged, but I need only changed. This trick doesn't solve the issue:
Build (TFS Build), only what is changed
Followed a couple of other sources.
IncrementalBuild property in TFSBuild project
Incremental builds in TFS
Applied these tricks to update project with few settings (IncrementalBuild =True, ForceGet=False, SkipInitilizeWorksplace=True, SkipClean=True) under PropertyGroup definition to the end of the TFSBuild.proj file.
But the issue still persists, we are unable to produce only changed binaries in build folder, there is always all files.
Please help me to achieve the desired build output.
Incremental builds only rebuild assemblies that don't depend on changed files. But it does copy all of the project output (subsequent projects that depend on it may depend on these assemblies and files being there).
This causes incremental builds to be much faster, but it doesn't "only deliver the changed files". It always delivers all files whether they are changed or unchanged. On top of this, you could have multiple agents and each agent can have multiple working folders, the incremental build could use any of these as base for the incremental builds, there is no guarantee that the changed files are between your previous build and the current one.
You'll have to implement this feature yourself, it has never been part of MsBuild or TFS Build. It would involve querying TFS for the last drop folder and performing a compare after running an incremental build. Then copying just the changed files and a log of deleted files.
PS: The TFSBuild.proj type builds are very deprecated. They have been surpassed by the XAML builds in TFS 2010 and have been considered "legacy" since then. They have subsequently been surpassed by the new VSTS/Azure DevOps build system which has deprecated the XAML builds. Most of the properties that interact with Source Control are ignored when a TFSBuild.proj project is executed in the Legacy XAML workflow. Instead, the XAML agent takes care of fetching the sources prior to passing control to MsBuild. These new VSTS/Azure Devops build tasks are now also getting YAML support for Git based source control repositories.
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.
I use Visual Studio 2015 and TFS 2012. In Team Explorer, it is possible to manage Builds and Build Definitions. Since VS2015, the section Build Definitions is named "XAML Build Definitions". I would like to put xaml build definitions in source control. Problem is I cannot find the build definition files on disk. Anyone knows where they are ?
Thanks
You can download build process template and add it into source control, but you can't version-control build definitions.
In the new build system coming with TFS 2015 you can see the full history of the changes to your build definition. The feature that is currently missing is the ability to undo or rollback to a previous revision. Check https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/2037625-provide-a-way-to-version-control-build-definitions
Just in case anyone needs to access the XAML Build Definitions parameters. They are saved in the TFS database, table: [dbo].[tbl_BuildDefinition].