We have a large code base with various labels which need autobuilding.
We are using TFS 2012 Express and VS 2010
Our code is build by a batch file so I have created a dummy solution which the autobuild builds, the build instructions for this solution just run the batch file.
I had the idea of using different configurations in this solution to build different labels.
So, as well as debug and release configurations I added one called LABEL which calls a different batch file and added a new automatic build in TFS which calls this solution with the 'label' configuration in the box Required - Configurations to build.
However, when I try to run it it fails claiming that the 'label' configuration does not exist.
Does anyone know how to do this?
Extra:
It seems to work if I use the Release configuration to call one batch file and the Debug one to call another but it still cannot find user created configurations?
If presume "Autobuild" means "build via TFS build definition".
If by "label" you mean a source control label, then when queuing a build, you can set its "Get Version" parameter to a label - for example, for the label MyLabel use LMyLabel.
If by "label" you mean some definition internal to the batch-file build, then you can pass it via an MSBuild property: Define it in the build definition by adding "/p:label=mylabel" to "MSBuild parameters". Then, where the solution calls your batch, you can use $(label) to get the value from the build definition.
Also, instead of this hacky .sln, you could modify the build template to call your batch file directly, and have a parameter which you set in the build definition, and the template passes it to the batch file.
Related
Is it possible to modify a web.config file in one of my projects during a Team Foundation Server build? Inside of my web.config file I have two setting keys: VersionNumber and BuildNumber.
Is it possible to change the value of BuildNumber based on the ID of the build in TFS?
Since you're using TFS 2013 you have an easier option than the old way of modifying the workflow - Use PowerShell.
If you're using the build template TfvcTemplate.12.xaml (which is the new default in TFS 2013), then you have some extra build definition parameters you can set to specify Powershell scripts to run. This way you just write a little bit of powershell code that gets the TFS Build Number (from an environment variable), then finds your web.config file(s) and changes them.
There is a sample script published in the TFS Community Build Extensions project that will do something very similar that you could modify. It finds all AssemblyInfo.cs files, then uses RegEx to modify them to update the build number based on the TFS Build number.
See the sample PS script here: https://tfsbuildextensions.codeplex.com/SourceControl/latest#Scripts/ApplyVersionToAssemblies.ps1
See some docs on how to modify the build to run PowerShell here: http://msdn.microsoft.com/en-us/library/dn376353.aspx
The answer is yes, though it's non-trivial. I've done this in the past using two methods.
Method 1: Use CodeActivities and alter the TFS Build workflow XAML file to include the new CodeActivity as a workflow step.
Here's an article on creating custom workflows with custom code activities (it's a little dated but still relevant):
http://blogs.msdn.com/b/jimlamb/archive/2010/02/12/how-to-create-a-custom-workflow-activity-for-tfs-build-2010.aspx
Basically, you create a new object that inherits from CodeActivity, create properties for your inputs (BuildNumber,VersionNumber, TargetFile), perform your actions on the TargetFile and save it. Then you wire up this new DLL with your activity to the TFS Workflow XAML, injecting your activity in the desired build step (post-build & pre-package in your case I bet to ensure xml transforms are applied).
Method 2:
Tag the desired properties onto the MSBuild invocation inside the TFS XAML file so they are passed in to MSBuild and available for your to use as $(BuildNumber) and $(VersionNumber). Then you can use MSBuild tasks to inject the properties into the file at the right time.
I have a single code based being used to build an application for multiple platforms.
Locally I have setup a main build-env.properties file, and a series of additional *.properties files that I use to switch settings for the different platforms I am publishing to.
Doing my build on the command line I simply use the command:
ant build -propertyfile dev-build.properties
How can I do this in Jenkins?
I currently use the "Invoke Ant" Build Step with the target set to build, but am at a loss for how to specify the secondary propertyfile?
Although not exactly the same, you can take the contents of those properties and put them into the Jenkins Invoke Ant build step, utilizing the properties advanced field.
The most basic way:
You will need to create a new task for each different set of sub properties you wish to utilize.
In your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field, you can copy the properties from one of your *.properties files into that field.
Repeat for each different properties file you wish to utilize.
Parametrized build plugin might help you. This is assuming the number of properties you are changing is one or two. So when you run a job, you get a drop-down to select you OS and go.
Though, as I have mentioned here , what goes against this plugin is that it makes the process manual
On this thread Hudson / Jenkins: share parameters between several jobs you can read the 2nd option in Anders's answer as an alternate approach.
A better approach for this is using a parameterised job with file parameter(refer to doc for creating the builds). Mentioning the file location as "propertyfile" would help. This would be better than reconfiguring the job again and again to run a build (To copy the properties file to the input location).
There's too much routine with building next project version using ant. The routine is in several properties files that must be edited before running ant task. I took a look at Jenkins as a system to make builds (including night ones) but I have a problem with changing properties.
Is it possible (if yes, how can I do it) to type parameters in Jenkins configuration before build in order they will be passed to ant?
What I really mean is the following schema (I used in manual builds):
there're 2 properties files that contain data about build version, src destination, emails to notify about new build and so on.
corresponding properties' keys are used in Ant tasks and these properties are changed manually before build.
some properties are read by Java util and used for their own part during build.
there're also 3 or 4 ant XMLs that a imported in build.xml, and these xmls also read properties from mentioned files.
What I want to do is:
change key properties in Jenkins
press build project
my data will overwrite data in properties files OR will be passed as ant vars values straight to the ant's task(s).
as a result I receive new build with corresponding notifications (they're made through ant)
Are there mechanisms that allow one to make such schema work via Jenkins?
Thank you in advance.
In Jenkins, you can use the parameterised build feature to specify those parameters you need to substitute into your build.
For example, if specify a parameter called server and, when clicking "Build Now", you enter test, the build will be executed with an environment variable you can access called ${server}.
Then, in your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field. Here you can enter my.ant.property=${server}.
That's equivalent to calling ant -Dmy.ant.property=${server}, and will be expanded to ant -Dmy.ant.property=test.
Another option : Set environment variables for the scope of the build using this Env plugin. So if the properties you are using are environment variables or can be set as them then you want to use this one. Though it might involve some effort in changing the build scripts, but it can be a good option :
Q : Why would I use this one as I already have parametrized build plugin
A : Because the parametrized build plugin requires human interaction if there is more than 1 choice. For example building for Release 1 or Release 2 or Test branch.
While in the Env plugin, you can set the property once for each choice and then create a respective job for each. Then just schedule the job(s) thereby eliminating the human factor.
In the TFS 2010 build definition window, under “Process” there are two required items. They are “Configurations to build” and “Projects to build”. Under projects to build, it will allow me to enter something like:
$/TeamProject/Area1/Area2/*
However, this doesn’t seem to do what I expect. The build fails because it’s looking for:
$/TeamProject/Area1/Area2/Sources/*
What I am trying to achieve by this is to build all the solutions held under this area. For example, I have:
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
There are many more solutions than this, which is why I’m looking for a way to build all solutions under the specified path recursively. Is there a way to do this in TFS 2010?
You can modify the process template. Expand it with the Matching files (I don't have the exact naming now) activity. Add a parameter that passes the information you set in the build defintion to the MachingFiles actvity. Then pass into the build solution activity instead of the argument that you enter in the build definition the files that is found by the MatchingFiles activity.
Now add a dummy solution in the build definition for the solution to build (it is not used anymore).
See the blog post series on the build customization for more information on customizing the build process template.
FWIW,
I've got: "configurations to build" blank
and under "projects to build" I've added my solutions via the ellipsis button
I would setup mappings for
$/TeamProject/Area1/Area2/Solution1/
$/TeamProject/Area1/Area2/Solution2/
$/TeamProject/Area1/Area2/Solution3/
Then in the build definitions enter the three projects to build
$/TeamProject/Area1/Area2/Solution1/Solution1.sln
$/TeamProject/Area1/Area2/Solution2/Solution2.sln
$/TeamProject/Area1/Area2/Solution3/Solution3.sln
You can leave the configurations to build as blank, or if you want to do a certain build you can set it to (for example) something like Debug|Mixed Platforms (check your Configuration Manager... for the solutions you are building to see what is valid)
Alternatively, you can just map the following (depending on how much you have in this folder, if you have Solutions 4+ that you don't want to trigger builds on, don't do it at this level)
$/TeamProject/Area1/Area2
And have one solution which contains the Solution1, Solution2 and Solution3, and build that instead.
By default building your Solution1 which is mapped to
$/TeamProject/Area1/Area2
On a build agent with a working directory that is going to looks something like:
$(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)
You'll end up with it being build under
C:\Builds\1\Solution1\Binaries
C:\Builds\1\Solution1\Sources
C:\Builds\1\Solution1\TestResults
Which is why you want to make sure that your OutDir's etc are all correct and not hard coded!
If you have a look while building, you'll see the build agent populating the Sources folder, and it should (if configured correctly) put all outputs into the Binaries folder (and then copy them to the Drop Folder configured under Build Defaults in TFS.
We are using TFS Build 2010 for Builds. We have two branches of source code (Lets say branchA and branchB).
Now as a part of the build definition we set the projects to build:
Now to employ the same build definition from branchB will mean that I create another build definition file with same content, with only the items to build set to "$/branchB"
Is there anyway to make this configurable, without having to edit the build definition?
Also there are other input variables that we set for the build definition, and the values for these variables are included in the build definition XAML file. So to change the value of a variable will mean that we have to edit the build definition XAML file. This is not desirable.
I would like to be able to set the "Items to Build" and the variables of the build definition without having to modify the build definition XAML file.
Are there any solutions to these problems?
You can modify the Build Process Template so it only asks you for the Items to Build. The rest of the arguments are prefilled. To get an idea how this works, see http://www.ewaldhofman.nl/?tag=/build+2010+customization
You can add parameters to your build definition. I did this a while back because we had two web projects in a solution that had to be deployed to different servers (via Windows shares). I added parameters to the build def so that in the build properties I could customize them depending on if it was a dev deployment, staging, etc.
I added a blog post on how to do it. You can use the parameters this way so that they aren't kept in the XAML file.
Deploying Web Apps with a customized Build Process in TFS