When looking at the list of recent builds for a Plan in Bamboo, there is column in the summary called "Flags". It contains values like "Custom build" (if you started the build manually using "Run customized") and "Custom revision" (if you ran the build against something other than the head of master).
Is it possible to add a step to my Plan that potentially puts my own value in this field for the current build? In particular, I want to have logic that does this based on build variable, basically saying "if this variable equals this value, then add this custom tag to this build" and have the tag show up in that column of the summary, letting me see whether each build used that specific value for the build variable.
I believe what you may be looking for will require two plugins created by Atlassian:
Conditional Tasks for Bamboo. This will allow you to trigger tasks based on variables.
Inject Variables. This will allow you to set certain variables in your tasks which can even be picked up by the other plugin.
Related
Is it possible to use a variable as build trigger? I've tried and the build doesn't get triggered. If I remove the variable and insert a value, the build gets triggered as expected.
Aren't variables allowed here? $(Mapping.ServerPath) is set to MyRepo/Branches/MyBranch. $/MyRepo/Branches/MyBranch triggers the build correctly.
No. And why should they?
The specified path results in a poll action being performed on the static path.
You can use wildcards if needed.
The build should trigger on a change, hence CI trigger.
Making the path a variable, when would you provide it?
If it's just keeping a static value elsewhere, why not fill it in?
If you want to provide the path when calling the build.
Then you don't intend to use the CI option as intended?
No, it is not supported.
There is a user voice that you can follow: Allow Variables in Repository, variables and triggers Tab.
We have a microservice architecture with dozens of builds, it makes sense to be able to use a variable that we can update when we start our next iteration. With our branching strategy we have a new branch for each sprint and for each release. Changing the CI trigger in every build every couple weeks is inefficient.
We are using on premise TFS2018 and from everything I've seen this is not supported.
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
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
How can i configure a build definition to allow me to pick a solution configuration at build time?
I have 3 configurations in my solution: (Local, UAT and Live).
I want people to pick and the configuration they need and the build will do the config transforms, deployment etc. as required. I have the build script I need, just need to know how I can switch upon the configuration.
If I cannot use the actual configurations, a custom property would do, but obviously I need to be able to access it in my build script.
My opinion is that your Build Defition should contain all three configurations, so that Build shall execute all three of them by default.Then, you can insert a custom argument in your build process template as an "Configuration Override" with default = empty.Checking this Hofman-post you can have your argument part of the 'Queue new Build dialog.So, when your users queue a new build, they either leave this empty and build executes all configs, or they enter one of the three and only the one selected shall be executed.There are various ways to implement this in your build process template, in general you might want to intervene in section For Each Configuration in BuildSettings.PlatformConfigurations:
and check if your custom argument is empty (so all nodes should execute), or if it is filled with a specific entry (so it should proceed only once). Further handling of a user input that does not comply with any of the available configs should be added, so that build can graciously fail.
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 ?