I have a CI process set up in TFS 2008 so that every time a check-in happens a build is triggered but only if a build is not already running. The exact setting used in the configuration is the radio button labeled:
"Accumulate check-ins until the prior build finishes (fewer builds)"
The checkbox "Build no more than every ___ minutes." is not checked
I have other build processes that might also be going on so I can see that a build is queued with a specific "Date Queued". When the build server gets to the queued build, let's say that it takes 10 minutes to get there, does it use the time-stamp of the queued build to do a get or does the build do a "get latest"?
I believe TFS will use the changeset of the last triggering commit (i.e. the build does a 'get specific version' by changeset ID, rather than a 'get latest').
You can check this by looking at the build report and finding the value for the 'Source control version' field, you should see something similar to this:
So first off, I would check that the value you're seeing for this is consistent with what you see in the build's workspace and that the build is referencing the expected changeset.
Assuming that your build is working as advertised (and this is a problem for you), then you may want to consider altering this default behaviour and force your CI build do a 'get latest' by overriding the 'GetVersion' MSBuild property in the build's TFSBuild.rsp file, by adding the following:
/p:GetVersion=T
Where 'T' stands for 'tip' (or 'head' in SVN parlance).
Related
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)
I have asked a similar question
TFS Build Configuration: get all the Work Items Details for a particular build
And based on the answer of above question I have the below query. I decided to start a new thread for new question rather than confusing people in same thread.
I am using a default XAML template for workflow of TFS build configuration. Now my requirement is that I need all the Work Items since beginning whenever I trigger a build event for any build definition regardless of last successful build.
Let say I have triggered first TFS build and it is succeeded then I triggered 2nd build and that is also succeeded.
Then I have opened the log file of 2nd successful build and goes to Diagnostics Tab of last build. Inside Diagnostics tab there is a section as “Associate the changesets that occurred since the last good build”
Inside this it will display a message like
"No change sets are submitted to build 'ABC…..'"
Whereas I require list of all the work items since beginning.
Please suggest me the changes which need to be done in XAML template so that I can get all the work items since the beginning of source code.
As we know, associate the changesets and work items only occurs since the last good build.
There is a simple workaround to achieve what you want, you can specify a previous changeset to queue a build, then build the latest changeset again, then you'll get the associated changesets and work items again. Refer to this blog: http://chamindac.blogspot.sg/2013/09/tfs-2012-get-release-build-with.html
Otherwise, you need to create a MSBuild custom task that makes a call to TFS for the items. Check the links below:
https://volatilecoding.com/2013/06/11/tfs-build-how-to-customize-work-item-association/
(this solution is for TFS2010/TF2012 build process template, you'll
need to work on TFS 2013 build process template).
http://devgorilla.net/?p=104
We are using the "new, scriptable build system" of TFS 2015 and all of a sudden one of our build definitions is gone. It seems that it deleted itself.
Is there a way to undelete/recover a build definition?
Where are the build definitions (those JSON files) acutally stored?
If you are on prem and you just chose delete from the GUI... run this in the TFS database for your specific id:
update Build.tbl_Definition
set Deleted = 0 --was 1
where DefinitionId = <your build ID goes here>
You will loose your build history without some extra work i did not take the time to dig into, but that might also be do-able.
NOTE: You will also loose credentials stored as build parameters you will need to recreate. Might even be best for you to recreate a new build using this as a template to avoid other unknowns.
TFS build definitions are not version controlled items. So, It's not possible to restore the deleted build definitions for now.
There has been a feature request in uservoice: provide a way to version-control build definitions According to the response from PM, this is still in process.
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.
We expect to get the rollback deployed to our service in the next few
months.
Chris Patterson
Program Manager
Moreover, the build definitions are stored in the TFS database.
I divide this to two issues , but solving any one of them will solve the other.
Issue 1:
When I use the section at the bottom of the following picture and add "configurations to release", the build is not triggering release management.
I queried the build logs for hours, and saw that it stops the release when it founds out that the configuration "does not match current"
If ConfigurationsToRelease Matches Current
Initial Property Values
Condition = False
Final Property Values
Condition = False
Final Property Values
Condition = True
before more words, I will show a picture that sums it up:
the build definition and ms build logs
in a default case, where configuration to release is blank , release management would continue from this point and write in the logs "Release the build" (as a command that happened) and the build would trigger release management.
If you look at my tfs build configurations, you can see it's exactly the same as the upper regular ms build configurations , but still I get this error of a mismatch.
In any case I only have only one dialog to fill my configurations at in build definition as shown in the 'configuration dialog' in the above pic.
I succeeded to release once or twice this way in this same project the other day by adding release configurations, it somehow worked, but then stopped working (worked once or twice as a glitch I think like something is cached there) but 99% of the other attempts failed, it was always stopping my trigger from tfs to release since the first time I tried it a few months ago.
Has someone here experienced it? I looked in a lot of places and spotted only one guy that complained about it. His solution was to remove it (not exactly a solution)
Is there a build argument that can fix this? (/p:something=something)
Issue 2: if anyone can solve it in a way different than rm configurations , then I don't need issue 1 to be solved.
For any one who is interested why I even messed with release configuration section of build definition, it's because I want rm to wait for all transformations to happen before rm intervention, and this seems like a way to tell rm , ok dude , see there? you got 2 configurations to wait for their build.
The thing is that by default when that configuration section is blank, rm is getting in the way of tfs build and tfs build is getting in the way of rm, something like a circular wait. rm expects both transformed folders to exist in build outputs when tfs build is waiting for rm to finish it's run after the first build, tfs wants to continue building the second configuration (and transform) but rm is involved already , seeking for it's second configuration, breaking the build when fails to find it, hence the second configuration will never be created, while rm is still waiting for it and tfs build waits for rm and build breaks. confusing? read again and see the pic below cause it's interesting enough.
more info for clarity:
the next stage of RM is trying to get something from build outputs folder before it's already there.
for example , if i set Release build to true , it will only build the first configuration (a folder is created, picture below) , rm will succeed in first step (QA.Release), and continue strait to try and grab Release for its next stage, but it's not built yet by TFS Build , which waits for rm to finish it's weird intervention in the middle of tfs's build work . and like i said above, I'm sure I've seen it work once or twice in one of my attempted builds.
the tfs output folder whith release build flag on(only one transform happens) \ when off (all two transforms work) + rm error when on (circular wait)
If I understand your situation correctly I think your problem is that you are building multiple configurations. This breaks one of the core tenets of continuous delivery which is that for a given release you should build only once and deploy that same build to each stage in your pipeline, in sequence.
In order to do this your build needs to be stage agnostic, which in practice means all your configuration (eg database connection string) needs to be tokensised so that the correct value can be swapped in for the particular stage (QA, Release etc). I have a blog post series here that explains the full process (for a sample web application) in great detail.
i managed to solve issue 2 , and by doing so, issue 1 is no longer relevant .
i switched to ReleaseTfvcTemplate.12.xaml as a build template (found on your C:\Program Files (x86)\Microsoft Visual Studio 12.0\Release Management\Client\bin)
and then the build finished all configurations before RM intervention .
truly seems like a bug in ReleaseDefaultTemplate.11.1.xaml , or this might be because i was using some additional msbuild arguments (which were needed) , or the fact i'm using slow cheetah to create transforms on a windows service (transformations are only introduced in web applications).
either way , i'm now able to perform advanced tasks , like using the transforms to add \ remove tags that should be different in production , for example , i can leave the use of diagnostics in the configuration file for qa use , and remove it for production to make the verbosity lower there . still am using RM PlaceHolders technique in conjunction to transformation technology , to enjoy both worlds where it comes to changes related to environments , but still keeping the principles by passing the same build (dlls) through all environments .
I'm trying to configure a set of build configurations in TeamCity 6 and am trying to model a specific requirement in the cleanest possible manner way enabled by TeamCity.
I have a set of acceptance tests (around 4-8 suites of tests grouped by the functional area of the system they pertain to) that I wish to run in parallel (I'll model them as build configurations so they can be distributed across a set of agents).
From my initial research, it seems that having a AcceptanceTests meta-build config that pulls in the set of individual Acceptance test configs via Snapshot dependencies should do the trick. Then all I have to do is say that my Commit build config should trigger AcceptanceTests and they'll all get pulled in. So, lets say I also have AcceptanceSuiteA, AcceptanceSuiteB and AcceptanceSuiteC
So far, so good (I know I could also turn it around the other way and cause the Commit config to trigger AcceptanceSuiteA, AcceptanceSuiteB and AcceptanceSuiteC - problem there is I need to manually aggregate the results to determine the overall success of the acceptance tests as a whole).
The complicating bit is that while AcceptanceSuiteC just needs some Commit artifacts and can then live on it's own, AcceptanceSuiteA and AcceptanceSuiteB need to:
DeploySite (lets say it takes 2 minutes and I cant afford to spin up a completely isolated one just for this run)
Run tests against the deployed site
The problem is that I need to be able to ensure that:
the website only gets configured once
The website does not get clobbered while the two suites are running
If I set up DeploySite as a build config and have AcceptanceSuiteA and AcceptanceSuiteB pull it in as a snapshot dependency, AFAICT:
a subsequent or parallel run of AcceptanceSuiteB could trigger another DeploySite which would clobber the deployment that AcceptanceSuiteA and/or AcceptanceSuiteB are in the middle of using.
While I can say Limit the number of simultaneously running builds to force only one to happen at a time, I need to have one at a time and not while the dependent pieces are still running.
Is there a way in TeamCity to model such a hierarchy?
EDIT: Ideas:-
A crap solution is that DeploySite could set a 'in use flag' marker and then have the AcceptanceTests config clear that flag [after AcceptanceSuiteA and AcceptanceSuiteB have completed]. The problem then becomes one of having the next DeploySite down the pipeline wait until said gate has been opened again (Doing a blocking wait within the build, doesnt feel right - I want it to be flagged as 'not yet started' rather than looking like it's taking a long time to do something). However this sort of stuff a flag over here and have this bit check it is the sort of mutable state / flakiness smell I'm trying to get away from.
EDIT 2: if I could programmatically alter the agent configuration, I could set Agent Requirements to require InUse=false and then set the flag when a deploy starts and clear it after the tests have run
Seems you go look on the Jetbrains Devnet and YouTrack tracker first and remember to use the magic word clobber in your search.
Then you install groovy-plug and use the StartBuildPrecondition facility
To use the feature, add system.locks.readLock. or system.locks.writeLock. property to the build configuration.
The build with writeLock will only start when there are no builds running with read or write locks of the same name.
The build with readLock will only start when there are no builds running with write lock of the same name.
therein to manage the fact that the dependent configs 'read' and the DeploySite config 'writes' the shared item.
(This is not a full productised solution hence the tracker item remains open)
EDIT: And I still dont know whether the lock should be under Build Parameters|System Properties and what the exact name format should be, is it locks.writeLock.MYLOCKNAME (i.e., show up in config with reference syntax %system.locks.writeLock.MYLOCKNAME%) ?
Other puzzlers are: how does one manage giving builds triggered by build completion of a writeLock task read access - does the lock get dropped until the next one picks up (which would allow another writer in) - or is it necessary to have something queue up the parent and child dependency at the same time ?