Good day. I would need to run the Bamboo plan which will dynamically get the branch at run time . For example , if i run the plan and it should prompt me for branch and lets say if i give feature_1 as my branch name , then it should build the feature_1 .
May i know how to achieve this ??
Thank you.
Bamboo doesn't satisfies this requirement directly. But this is how you can try to achieve same. Check the below steps you need to follow.
In Bamboo build plan configuration, goto variables and add a variable for branch path. This is path of the branch which you want to build. e.g. Feature1, Feature2 branch path. etc
In Plan repository, create SVN repository 'Build Script' and add repository path for common build script. You can use Perl script for this.
Now in bamboo job, create a 'Command' task to execute this Perl script.
When this common build script will gets executed, it will checkout desired branch specified at step 1 in plan variable. You have to use SVN command line to check out the branch.
Post branch checkout, common build script will then call branch specific build script (which was checked out at step 4). Which will then do the job for that specific branch i.e. Compiling code, Packaging etc.
So whenever you want to take build for any specific feature/brnach, then you just have to change the SVN path for branch path plan variable created at step 1 and run the plan. Thats it.
Let me know if you need more clarification.
~Nilesh
Related
We're using Go.Cd and transitioning to Bamboo.
One of the features we use in Go.Cd is value stream maps. This enables triggering another pipeline and passing information (and build artifacts) to the downstream pipeline.
This is valuable when an upstream build has a particular version number, and you want to pass that version number to the downstream build.
I want to replicate this setup in Bamboo (without a plugin).
My question is: Is there a way to trigger a child plan in Bamboo and pass it information like a version number?
This has three steps.
Use a parent plan/child plan to setup the relationship.
Using the artifacts tab, setup shared artifacts to transfer files of one plan to another.
3a. At the end of the parent build, dump the environment variables to a file
env > env.txt
3b. Setup (using the artifacts tab) an artifact selector that picks this up.
3c. Setup a fetch for this artifact from the shared artifacts in the child plan.
3d. Using the Inject Variables task - read the env.txt file you have transferred over. Now your build number from the original pipeline is now available in this downstream pipeline. (Just like Go.Cd).
I'm not really sure if I got bamboos workspace handling right...
We have the following situation:
stage1:
job1: scm checkout
stage2:
job2: build1
job3: build2
stage3:
job4: build3
job5: build4
The repositorys size is about ~1,5 gb. Therefore, after every build, I want to delete everything except the build artefacts on my agent. But if I delete something on my agent in stage2, my jobs in stage 3 only get the "cleaned" ws. Is this default behaviour? And if yes, how can I prevent that my agent gets "dumped"?
x jobs = x*1,5gb ...
If you want to delete the working dir, go to Job configuration / Miscellaneous tab and check Clean working directory after each build.
I haven't found this option in the documentation, anyway its there (Bamboo 6.0.3)
Also note, that if you have more than one agent, jobs might run on any of them (concurrently). So job1 (checkout) could theoretically run on another machine, than the rest. You can solve that with Tasks, which always run inside one Job, thus one agent.
In TFS 2015 I have the following structure for a Project:
ProjectA
Scripts
SystemA
SystemB
SystemC
Now let's say I have a build definition for SystemA with the following mappings:
$/ProjectA/SystemA/trunk/src
$/ProjectA/SystemA/trunk/deploy
When I build SystemA the source branch will be:
$/ProjectA/SystemA/trunk
I will be able to see the changeset for the build only for SystemA (what I expect).
Now let's say I want to add a powershell script to my build definition in the Scripts folder. Here are the new mappings for SystemA's build definition:
$/ProjectA/SystemA/trunk/src
$/ProjectA/SystemA/trunk/deploy
$/ProjectA/Scripts
When I build again SystemA, the following source branch will be:
$/ProjectA
The problem now is when I click a build done and troubleshoot the errors why the build failed, I have all the changesets from SystemA, SystemB, SystemC and Scripts.
I would like to manually set the Source Branch for the changesets to $/ProjectA/SystemA/trunk/, even if Scripts is outside of that scope and being used. Is there any way to do that?
We are not able to change the Source Branch, it capture the same part in all mappings. You could consider create the Scripts folder under $/ProjectA/SystemA.
When creating your mapping, instead of
$/ProjectA/Scripts, type
$/ProjectA/SystemA/trunk/../../Scripts
and it will trick it to use $/ProjectA/SystemA/trunk as the branch.
Unfortunately, I think this is more a bug than a feature since once saved, the path is shown as $/ProjectA/Scripts and that if you save again without manually setting the backward path again, the original situation comes back. Anyhow, it works as long as you think of setting the path each time you need to modify it.
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 a build plan in Bamboo (5.10.0, build 51017), and in the end of my build process, I push changes to my Git repository (Bitbucket Server), with a message with the following format: <build key>: Commit performed by the build server..
My build plan key is AAB-AC, and the commit message always starts with the key of the build, such as AAB-AC7-JOB1-75 (${bamboo.buildResultKey}).
I have tried many different regular expressions in the Exclude changesets field of the Advanced options of my repository, but a new build is always triggered whenever a build completes.
Here are a few examples of the patterns I have tried:
^AAB-\S*-\S*-\d*:
^AAB-AC\S*-\S*-\d*:.*$
^AAB-AC
AAB-AC
^AAB-AC\S*-\S*-\d*:.*\n
^AAB-AC.*$
^AAB-AC.*-.*-.*:
Commit performed by the build server
For each of these regular expressions, whenever I run a build manually, a new build is started right after my build finishes and the Bamboo server enters an infinite loop and endlessly builds my app.
How can I make Bamboo ignore the commits performed by my build plan?
Thank you for your help!
Most of those should work, we use ^Tag:.*$ in "Exclude changesets" to exclude commits like "Tag: v1.0.0" from triggering a build.
This worked in Bamboo 4, but doesn't work since we upgraded to 5.10.2 build 51019. So my guess is that this is a bug in Bamboo
I finally managed to make this work...
I have branches on my plan and I found that branch plans have their own repository definition with their own Exclude changesets setting.
So I tried all the regex combinations for nothing since the value specified on the branch plan was used, and not the value I defined on the main plan...
It seems that the ^ character is used to negate the regex, instead of matching the beginning of the string...
So the pattern ^AAB-AC seems to match everything that does not contain AAB-AC
All the commits I pushed to my server that didn't contain AAB-AC were ignored
All the commits pushed by my build plan triggered a new build
So I fixed my regex and I updated all my branch plans and everything seems to work properly.
Thank you for your help,
Best regards!