I'm creating a custom build process template that allows the person who is queueing the build to define the build and revision numbers (as they are used on the assembly version info).
However, if the build fails, they can't queue a new build for the same version (but they should be able).
Is there a way to automatically discard the build if any step in the workflow or MSBuild Script fails?
TFS maintains assigned build numbers in the database itself, for its own administrative purposes. This maintains its internal consistency with all the assets that are produced and (intermediate) work products.
The only way to free up a previously used build number is to actively DESTROY it from the database. Please see http://geekswithblogs.net/jehan/archive/2011/04/23/tf42064-the-build-number-already-exists-for-build-definition-error.aspx for a further explaination.
One of the features added in TFS 2012 is the ability to retry a build.
This allows you to right click a failed build and select retry instead of queuing a new build. This should allow you to run a build with the same configuration settings without getting errors on your build numbers.
Related
We have upgraded from TFS 2013 to TFS 2017, One feature we are trying to implement that we had in 2013 was the ability to have a custom build number. the previous method we had a file called BuildVersion.XML which during the first build step would read the major,minor, and revision and name the build with that build number + 1 on the revision. It would then change then checkout and update the revison number and check in the new version. I know that there are steps where people update the AssemblyInfo. The issue is that not all our code is .net apps. we also now have SSIS Packages, Cordova iOS/android apps, angular sites, aws Lambda functions with node.js which do not have the concept of AssemblyInfo. is there an easy way to implement this?
You can do exactly the same thing in Team Build in TFS 2017.
You can update the build number from any task by calling:
Write-Verbose -Verbose "##vso[build.updatebuildnumber]1.2.3.4"
Add a PowerShell task and add an inline script to read from your file and update the build number with the above.
You can then have additional scripts that use the build number any way you need to version your application.
You can see the full list of logging commands here
https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
You can use my VSTS TFVC tasks to interact with source control, though I do not recommend it. I built these tasks for clients of mine who were doing exactly what you are doing.
Instead of relying on a file in source control it would be a much better solution to pass the BuildNumber from the Build Definition along to the build, have one of your first steps update the files on disk with the correct version number then run your build.
If you manipulate files during the build and check them in you run the risk of inconsistent numbering when you scale up to multiple build agents, it's hard to use in combination with parallel builds and build variable multiplexing and it becomes notoriously hard to do Gated Checkins and Shelveset builds. Plus, it limits your options to move to Git in the future.
This seems simple enough, but I can't find a solution for this online.
I am integrating SonarQube into our build definitions that get triggered on check in. I want the version SonarQube uses to be tied back to the project number defined by the business side of things.
Ideally, I would like to be able to prompt the user for input. When you go to check in and it kicks off the build, it would ask you for the project number to be used as the version for SonarQube. Is this something TFS 2015 supports?
User input for build definitions
As far as I know, build definitions that are not manually triggered do not prompt for user input. A prompt allowing users to set build variables is shown for manually triggered builds from the VSTS web page.
SonarQube project version
I would recommend against you using the build or assembly version in your build tasks. This is because the SonarQube concept of version is quite different from the build concept. SonarQube uses versions as a baselining mechanism / to determine the leak period. If you up the version number often, the leak period is going to be too short to be actionable.
I'd recommend keeping the SonarQube project version in sync with your release schedule instead.
The short answer to this question is no, there is no way to prompt for input on a non-manually triggered CI build.
Here's what we did to work around this:
I wrote a Powershell script to read a config file and set the values to environment variables exposed to later build steps. Those variables are then what are specified in the Sonar Begin Analysis build task. I packaged that script up as a custom build task that will read a "sonar.config" file. This means all we have to do is add a "sonar.config" file to each solution we want to run Sonar analysis for, defining the key, name and version for the project, and then this build task will populate all necessary environment variables as the first step in the build.
So not a perfect solution, but it gets the job done without us having to add a lot of extra code to our solutions.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
We have a nightly TeamCity build which releases the latest code to our test website, restores the database to match production, then applies any schema and data changes we have in TFS.
If this nightly build fails, the website is down until we manually fix the code and/or the database scripts and restart the build.
What I'd like is to automatically rollback to the last successful build so the website is available despite of any build break.
After spending a bit of time investigating, here's my proposed solution:
Nightly build runs, creating a new label in TFS (something like Nightly-build-{build number})
Create a new TeamCity build which triggers after the nightly build runs
Find the last successful nightly build number
Get the version relating to that build number's label in TFS
Rollback builds (it doesn't matter if the nightly build just finished successfully)
What I don't know is how to have the rollback build get the version based off a label.
Any help for this, or another solution, would be appreciated.
Cheers.
A judicious use of the TeamCity REST API might work here. I'm cribbing a bit from this question, which covers some of this same territory. You might could do something like this (and I'm just spitballing here):
Create your VerifyBuild configuration as per your Step 2.
Create a RollbackBuild configuration that can deploy from a given label, the build number of which is parameterized as %rollback.buildnumber%
In VerifyBuild:
Use the Rest API to list the most recent nightly production deployments
If the most recent deployment was a SUCCESS, then you're done.
If the most recent deployment was a FAILURE, then get the build number of the last successful build.
Use the Rest API to set the %rollback.buildnumber% of the RollbackBuild to the last successful build number.
Use the Rest API to queue a RollbackBuild.
I'm proposing this method because I don't know how you would dynamically fetch the correct label for RollbackBuild prior to the checkout, so I'm using VerifyBuild to pre-populate it.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.