I have two team builds created in VS 2013 - Dev and Test - using the TfvcTemplate.12.xaml build process template. Both builds also use a custom .proj file defined in the process tab "Build/Projects" parameter.
Dev is set to Continuous Integration to build on each check-in. For the Test build, I'd like to update to a particular version.
When firing the build manually, in the parameters tab, I have successfully been able to specify a Changeset in the "Get Version" option. (C9999)
1) I'd like to eventually fire this build from command line, so is it possible to pass this in as a /msBuildArgument instead? e.g. /p:GetVersion=C9999
(I've tried this, and it successfully passes GetVersion to my .proj files, but it does not override the iBuildDetail.SourceGetVersion, which I think is what needs to happen to tell MSBuild what version to get from source control.)
2) Would using the "Label", "BuildId" or "BuildNumber" be better options, and if so, can I specifiy them as /msBuildArguments?
I have found a few related posts, but these offer suggestions that don't seem directed to 2013, but rather 2010 and 2008.
This screenshot shows where I can successfully enter and build a specified changeset and what I'm attempting to pass via arguments.
I found some buried documentation which indicates to prefix the label with an "L". Setting Get Version = "LlabelName" did the trick.
https://msdn.microsoft.com/en-us/library/gg490833.aspx#VersionSpecs
This is helpful, but it seems the labels are tied the to the build's retention policy. For this reason, I'll be using Changesets to specify the version I want to get (build and deploy).
Also, I found a couple parameters to specify Changeset (or labels) to add to the TFSBuild start command I am executing from the command line:
/getOption:Custom /customGetVersion:C9999 (or LlabelName)
Related
I have a folder in TFS which has SQL Scripts. At the moment I am manually adding a comment and updating a version number inside the comment every time i make a change and check it back it. This works however was hoping there might be a better way. Is there a way to automate this in TFS?
I have read the following article
Version control project files
do i have to go through such a process for simple .sql files? Are there any other simple ways.
There are a few ways you can do this:
Create an automated build in TFS and write a custom build step / PowerShell script to parse the appropriate SQL scripts, read the version, increment it, and store the new version by either checking in the updated file or a local store
Use a database project (part of SQL Server Data Tools) which will output a DACPAC. Inside the database project, you can set the version as specified here. This stores the version in the project file. If you update your TFS build number to be digits only, you can then update the project file to set that value to match the build using a custom build task. For example, if your build number was yyyy.m.d.R where R is the number of times that build was run today (TFS manages that - it's the revision variable). Or, you could set the the <DacVersion> tag to something like 2.1.0.0 and your build replaces the last digit with yyyymmddr.
I'd recommend using a database project. It's pretty easy to create a new database project off an existing database.
The first way mentioned by Jacob above can achieve that if you just want to incremental the version number of the script/folder, just create a CI build definition.
Actually you can just enable Label sources and set the Label format with predefined environment variables such as $(build.buildNumber), and set without publish any artifacts during build process.
Thus, it will automatically trigger the CI build when you check in files, and the source (SQL Script /folder) will be labeled with the incremental number.
Then you can find the specific versions with the label.
I have the following variables defined:
Now once a build is complete (the last step in the build process), I want to update the VersionRevision variable, basically increment it.
So I'm looking for an API I can call from C# and create a console application or a powershell script to edit the build definition (if I have to do this)?
You can use VSTS Rest API to update the variable value in Build Definition. Both Console Application and Powershell Script is OK for this.
If I understand correctly, you want to get these build variables and them assignment them as your version number.
After the build completes, update and increment the VersionRevision. It's not a good way and seems not available to achieve it.
In TFS build there is a $(Rev:.r) which means
Use $(Rev:.rr) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
Source: Specify general build definition settings
To version your assemblies you could just add an powershell script in your build definition, detail ways to achieve please follow this link from MSDN: Version your assemblies
And usually we only define and assignment variables with the Major and Minor version. If you want to change the value of them. You may need manually edit the build definition.
More related link about how to manage version numbers as part of your vNext builds.
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
I have set up a Build Definition to build a solution on Visual Studio Online (VSO). It's working fine, but it builds all the code every time when I check in the code.
How can I build a particular changeset from the code?
How can I use/pass this number to the "MSBuild Arguments" to use it there for deployment?
You need to turn off the CI build feature(Uncheck "Continuous integration (CI)" option under "Triggers" tab in your build definition) if you don't want it to build all the code every time when you check in.
To build a particular changeset, you can enter the changeset number in "Source Version" textbox when you queue a new build. (In Git, it is "Commit" textbox)
To pass the version number to MSBuild Arguments, you can use the pre-defined variable "$(Build.SourceVersion)", it is filled with the source version number you specified when you queue the build.
I am attempting to follow the tutorial for CI with Azure and a Team Foundation Build Server located here, but am running into an issue with the configuration of the build configuration template XAML file, in Step 5. In trying to configure a new ConvertWorkSpaceItem, and add it to the modified build template TFS provides (TfvsTemplate.12.xaml) so that a custom script can be run on a TFS build agent, I attempt to set the property Workspace = "Workspace", but am given a compiler error: 'Workspace' is a type and cannot be used as an expression.
I've done some troubleshooting already, and the errors that have happened to others -- not scoping the CreateWorkSpaceItem, or using the wrong version of TFS or Visual Studio -- do not seem to be issues. I placed the logic correctly inside the "Run on Agent" block, so the scope should be right, and Visual Studio and my TFS Server are both running 2013. My only thought is that the instructions are out of date, and there is some other step that needs to be taken that I am missing. Any ideas?
EDIT:
Here are the parameters for the first failed convert item. The second failed Convert item is similar. The Input and Result variables are parameters defined by me for the workflow as part of the instructions for the tutorial. The error displayed is: "Compiler error(s) encountered processing expression "Workspace". 'Workspace' is a type and cannot be used as an expression."
ok this has come up a couple of times now, for TFS 2013.
Built in variables used to be available for
SourcesDirectory, Binaries Directory and Workspace
these are no longer available in TFS 2013 you now have to use
Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables
to access these.
Getting the workspace is a little more complicated but if you assign some local variables you should be able to get the workspace object.
Declare local variables for sourcesDirectory (string) and buildDetail (IBuildDetail) and workSpace(Workspace) set their scope to the whole workflow
Create an GetEnvironmentVariable Activity and set its Result value to be sourcesDirectory and use Microsoft.TeamFoundation.Build.Activities.Extensions.WellKnownEnvironmentVariables.SourcesDirectory.
Repeat the same for buildDetail = WellKnownEnvironmentVariables.BuildDetail
Create an assign task for the workSpace object, set this one as
workSpace =
"[buildDetail.BuildServer.TeamProjectCollection.GetService().GetWorkspace(sourcesDirectory)]"
This should then give you a Workspace object to use.
note: syntax might be slightly out.
To compliment the removal of these variables MS have added a new Activity
GetLocalPath
which may be of use to you instead
my build process with TFS 2010 should perform different task one after the other like:
Build 1st project in solution
Execute MSBuild via command line (to publish the project)
Execute a 3rd party tool via command line (to obfuscate the binaries)
Build a 2nd project in the solution (an InstallShield project)
How can I achieve this? I can define several project in the Build Definition but how can I invoke several command line task between these build steps? And the MSBuildArguments in the Build Definition: Are these arguments for every msbuild call for each project/solution?
Thanks
Konrad
At first, you need to add in your build definition the distinct *.*proj instead of one big *.sln - or (even better) construct more than one *.sln & order them to get build in the build definition. So you could organize a Project1.sln, Project2.sln etc that are only used from the Build.
In addition to that, you would have to make changes in the build process template to get this.By default you get something like that, that executes each set project/solution within a bigger foreach:
A good way would be to enhance this as a sequence, where all your custom action are set as InvokeProcess activities:
Obviously, you would have to insert here a flow control, so that Publish & Dotfuscator execute the first time (where Project1.sln gets build), while ISDEV executes the second time (where Project2.sln gets build). In the sample below I used a switch & packed Publish & Dotfuscator in a new Sequence.
Finally, you would have to have a counter of some sort. The most immediate option is to set a new Int32 Variable with default == 1 and increase it by hand during execution. In the sample below this is done in the lower Assign:
This final override of Complie the Project, along with a changed Build Definition should get what you 're after.
The team build definition takes a list of sln's and msbuild project files. You can put simply split your InstallShield project out into it's own solution ( most developers won't have a copy of InstallShield anyways likely ) and write an msbuild targets file for steps 2 and 3. Then just tell your build definition to build solution 1, the targets file and solution 2.
You could also choose to put the stuff in the targets file in a postbuild event for one of the projects in solution 1.
I wouldn't do this in workflow.