Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Using build variable in subversion URL

Dennis Ryan August 10, 2011

In my development environment, there are about 10 projects, for each project, there are at least two builds (regular, and slower daily builds). Because of this, I would like to keep the bamboo configuration as generic as possible. According to the documentation, the following subversion URL ought to be valid. However, it looks like the substitution does not happen.

svn+ssh://svnrepos/myrepos/trunk/${bamboo.buildPlanName}

The logs show an SVNException:

atlassian-bamboo.log:Caused by: org.tmatesoft.svn.core.SVNException: svn: URL 'svn+ssh://svnrepos/myrepos/trunk/$%7Bbamboo.buildPlanName%7D' non-existent in revision '49,210'

3 answers

1 accepted

0 votes
Answer accepted
PiotrA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 11, 2011

You can't use "bamboo.buildPlanName" variable in the source repository URL substitution (as well as you can't use "buildNumber", "buildKey", "buildResultKey" nor "buildResultUrl") - these all are empty during code change detection. Where is the documentation that says the above subversion URL (svn+ssh://svnrepos/myrepos/trunk/${bamboo.buildPlanName}) ought to be valid? I'd like to look at the documentation and compare it with my findings...

Dennis Ryan August 11, 2011

Oh, I see the errors of my ways. In my enthusiasm, I missed that the 'avalable variables' column clearly does not build-specific variables!

Still, I wish it were possible as 99% of our builds have identical configurations with only the svn url differing. This can't be that unusual of a situation.

http://confluence.atlassian.com/display/BAMBOO/Using+Global%2C+Plan+or+Build-specific+Variables

Variables can be used in the following fields of your build plan:

<th class="confluenceTh" style="font-size: 10pt; line-height: 13pt; color: #000000; background-color: #f0f0f0; text-align: left; vertical-align: top; min-width: 0.6em; border-color: #dddddd; border-style: solid; padding: 5px;">Field</th><th class="confluenceTh" style="font-size: 10pt; line-height: 13pt; color: #000000; background-color: #f0f0f0; text-align: left; vertical-align: top; min-width: 0.6em; border-color: #dddddd; border-style: solid; padding: 5px;">Available variables</th>

...

Repository URL (for Subversion repositories only)
— see Specifying the Source Repository for a Plan
Global variables
System variables

PiotrA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 11, 2011

How about using Plan Variables?

Dennis Ryan August 12, 2011

I'm not sure I follow, or (likely) I have not configured my projects/plans well and can't take advantage of this. Here is Project->Plan configuration I'm presently using: (the structure has changed since my initial message... lots of playing around...sorry for the moving target...)

Project1->trunk->DefaultJob (svn: http://svn/trunk/Project1)

ant clean all test -Dquick=true

Project1->daily->DefaultJob (svn: http://svn/trunk/Project1)

ant clean all test

Project2->trunk->DefaultJob (svn: http://svn/trunk/Project2)

ant clean all test -Dquick=true

Project2->daily->DefaultJob (svn: http://svn/trunk/Project2)

ant clean all test

...You can see where I'm going. My projects all have a common layout, and build targets. If I need to add more projects, which I do, or if I need to change my ant target in the future, and I'm sure I will. What is the best way to do that? Is there a true path to Bamboo nirvana???
Thanks!
1 vote
Przemek Bruski
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 13, 2011

The only kind of variable that will be available to you during change detection is a 'capability' variable (like JDK=c:\Program Files\Java).

All other variables require a build context when they are applied and a build context is not available during change detection.

So no, there's no path to "Bamboo nirvana" as you put it, sorry.

The idea you had sounds good though - binding project names/plan names/job names to repository paths does sound like an efficient way of reducing redundancy in plan definitions between developers/projects/branches. I think it's best if you submit an improvement request.

Dennis Ryan August 14, 2011

Thanks Przemek,

You've been a great help. One thing that I did which should help me out in the future is I put my build targets in global variables standardBuildTargets and dailyBuildTargets, etc...

I will submit a feature request.

0 votes
jfachal February 3, 2016

What about plans with no automatic triggers?

Why in that cases is not posible to change dinamically the property "SVN Repository URL".

I think this situation is perfectly posible. And I think is very useful.

I would like trigger a plan manually with the option "Run customised" (changing the plan variables and finally the repository url be altered)

 

 

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events