Child pages
  • Bamboo Tagger plugin
Skip to end of metadata
Go to start of metadata


Bamboo Tagger plugin



Product Versions



Ross Rowe, Jonathan Doklovic [developer(at)sysbliss(dot)com]








Subversion URL or browse via fisheye

Download JAR

bamboo-tagger-plugin-1.0.8.jar (supports Bamboo 2.1.3 and lower)/bamboo-tagger-plugin-1.1.0.jar (supports Bamboo 2.1.4)/bamboo-tagger-plugin-1.2.1.jar (supports Bamboo 2.1.5)/bamboo-tagger-plugin-1.4.0.jar (supports Bamboo 2.2)

Download Source



A plugin for Bamboo that provides a post build action to tag completed builds for plans using Subversion, CVS, Perforce and ClearCase repositories.

Due to the changes in the underlying Bamboo API, version 1.1.0 of the Tagger plugin should be used with Bamboo 2.1.4, version 1.2.1 of the plugin should be used with Bamboo 2.1.5 and version 1.4.0 should be used with Bamboo 2.2


The plugin can be installed by copying the bamboo-tagger-plugin-1.4.0.jar file in the BAMBOO_INSTALL/webapp/WEB-INF/lib directory.

Once the plugin has been installed, an extra set options will appear on the build plan's Post Actions page (on the Configuration screen). Here you can specify if you'd like to enable Post Build Tagging of Builds. If this option is checked, then you are presented with the option to enable tagging of failed or successful builds (or both).

Within each option, you can specify the label of the tag and the destination. The destination field is only required for plans using Subversion as the source code repository.

The plugin supports the following replacement variables within both the 'Tag Label' and 'Comment Text' fields:

  • %B - this is replaced by the build number
  • %C - this is replaced by the SCM comments included with the change set being built
  • %J - this is replaced by the Jira issues included with the change set being built
  • %d{ddMMyyyy} - this is replaced by the current date, in the format specified within the curly brackets. The date formatting characters are those specified by the Java SimpleDateFormat class.

The plugin also supports the usage of Bamboo Global or Build-specific variables (eg. ${bamboo.buildNumber})

If a build has been enabled to tag a successful/unsuccessful build, then a new tag will be created once the build has completed.

Version History





5 Nov 2009

Recompiled plugin to


19 April 2009

Included updates to Perforce support to only tag those versions included in build (thanks David!)


15 Mar 2009

BTP-2 Included support for ClearCase. Updated plugin to support Bamboo 2.2


15 Feb 2009

BTP-1 Log tag success/failure information to build log


8 Dec 2008

Updated plugin to support Bamboo 2.1.5


8 Dec 2008

Updated plugin to support Bamboo 2.1.4


28 Oct 2008

Ensure that CVS output is logged to the bamboo.log file


25 Oct 2008

Updated CvsTagger to use correct source code location


24 Oct 2008

Fixed critical bug in build configuration present in 1.0.5, see comments


22 Oct 2008

Added ability to specify either 'rtag' or 'tag' for the CVS support. Version 1.0.5 contained a critical bug, users should use 1.0.6 instead


20 Oct 2008

Added ability to specify the comment used for the tag via the configuration, and also added the ability to include the Jira issues and SCM comment information as replacement variables, which can be used in both the Tag Label and Comment Text fields


5 Sep 2008

Fixed issue with custom build properties not expanding properly


27 Aug 2008

Included correct version in plugin descriptor


22 Aug 2008

Ensured that the custom configuration of the build definition is used as part of the variable substitution


8 Aug 2008

Added ability to delete contents of tag prior to tagging a build in Subversion


5 Aug 2008

Use vcsRevisionKey for Subversion tagging


4 May 2008

Added i18n support


29 Apr 2008

Added some more unit tests


25 Apr 2008

Ensure that Subversion destination urls that have trailing slashes generate svn copy correctly


20 Apr 2008

Added support for global/build variable replacement in tag name


9 Apr 2008

Added support for Perforce tagging


7 Apr 2008

Added support for CVS tagging


28 Mar 2008

Added support for Subversion tagging


25 Mar 2008

Initial plugin version



  1. Hey Ross,

    Cool to see your submission.

    This is definitely one we wanted to do for a while now - so it's cool that you're on it here!

    One idea - for the tag - you might want to use the meta-data substitution syntax that we use for other configuration screens (e.g. ${bamboo.buildNumber})? Some information on how to do this is here:


    1. Hey Edwin, thanks for the heads up re: the substitution syntax, I'll definitely look at incorporating it into the plugin.



  2. This plug-in would be real useful – if I could get it to work!

    I have set up:

    Post Actions
    Tag Successful Builds
    Tag: foo_%d{yyyyMMdd}
    Destination: svn://

    This is what happens:

      2008-04-24 16:26:04,163 ERROR [pool-8-thread-1] [SubversionTagger] 
      org.tmatesoft.svn.core.SVNException: svn: Commit failed (details follow):
      svn: Path 'tags/foo_20080424' not present

    Any ideas?

    1. Make sure that the 'tags' parent directory already exists before trying to tag. SVN will create the new tag directory, but won't create the path up to that point.

      1. Thanks, I've checked that. Just to be clear, I'm expecting the final tag URL should be something like:


        Everything up to foo_20080424 exists already (and contains some other "tags" with different names). Perhaps I should try to enable more verbose logging to see what's going on?

        1. I've just checked this, and I replicated the error when the destination url has a trailing '/'. However, if I try this without a trailing '/', the tag gets created successfully.

          Can you update the destination to not include the trailing '/' and try again? In the meantime, I'll update the code to work with trailing '/'s and will release a new version ASAP.



          1. Just FYI, I've put up a version 0.0.6 which should fix the problem

          2. Thanks for the quick response. Removing the trailing slash does indeed fix the problem!

  3. Just looking at the source code, for the subversion tagger, I see the following


            SVNRevision.HEAD, destinationUrl, false,         "Automatic copy from Bamboo");I'm concerned that the use of HEAD will mean you are not necessarily tagging the version that has just been built?

    1. Hi Mark, thanks for pointing that out, I'll attempt to fix this to make sure that the correct copy is being tagged.



      1. Hi again, I've just released 0.0.9 which now uses the Subversion revision number used for the build for the copying operation.



  4. Hi Ross,

    It would be nice to support JiraVersions variables such as, bamboo.custom.jiraversion.rawname,bamboo.custom.jiraversion.type, bamboo.custom.jiraversion.released when defining tag labels! 

    Do you probably know some quick workaround or solution?


    1. Hi, I haven't tried the JiraVersions plugin yet, but the Tagger plugin does already support the substitution of variables (such as those specified on the Using Global or Build specific Variables page. I'll try to setup my environment to make use of the JiraVersions plugin...I suspect it shouldn't be too difficult to include the variable substitution (if it's not already there).



    2. Hi again, I've just created version 1.0.1, which should support the replacement of the JiraVersions variables. Please note that the parameters are stored without the preceding 'bamboo', so for the '' parameter, you should include ${} in the tag label.



      1. Thanks for the quick release, Ross! I'll test it.

      2. Hi, I tried new build and it does not seem to work... For some reason only
        bamboo.buildKey replacement works for me.  None of bamboo.buildNumber, bamboo.buildResultKey
        and all of bamboo.custom.jiraversion.* variables don't work. (As you recommended I used
        format you mentioned above in the tag label). Where else should I look?


        1. Hi, a couple of things, I was wrong about the including bamboo at the beginning of the variable, it turns out you do need it. Also, the JiraVersions variables begin with 'custom.jiraversions.' rather than 'custom.jiraversion.'. For instance in my environment, I have managed to define a tag with a '${bamboo.custom.jiraversions.jira.projectkey}' variable present, which seems to get resolved correctly.



          1. Hi, here the Usage sections is the list of variables I would like to use. They say I should use 'custom.jiraversion' instead of  'custom.jiraversions' use recommend. However I tried your variant but the behavior was the same.

            Note: The only bamboo.buildKey is being substituted in my case.

            The env. : Bamboo version 2.1,  bamboo-jiraversions-plugin version 1.2.0,  Bamboo Tagger plugin 1.0.2. 



            1. Hmm, I'm not sure what's going on, but I'm using the same versions, and when I use 'success_$

              Unknown macro: {bamboo.custom.jiraversions.jira.projectkey}

              ' as the tag label, 'success_TST' is output (where TST is my Jira project name). I've sent an email to the developer of the JiraVersions plugin to see if he's got any ideas.



              1. Hi, the bamboo.custom.jiraversions.jira.projectkey variable you mentioned definitely works.

                But what about others variables such as s, bamboo.custom.jiraversion.rawname, bamboo.custom.jiraversion.type, damboo.custom.jiraversion.released and ?

                Could you please check in you env?


      3. Ross,

        I've also had a play with the latest 1.0.1 plugin.

        It seems like most of the variables don't work. I looked into this further, and found that the plugin jar for version 1.0.1 is actually v0.6 (as specified in the atlassian-plugin.xml)?


        1. Hi Edwin, I had the wrong version included in the plugin descriptor (the version in the pom file was correct though)...I've just released 1.0.2 which should fix this.



  5. Can anyone let me know if this is working now?

    For clarity....  all version related info that the end user would want is correct on the JiraVersion plugin page, i.e.:




    the build key. (i.e. PRJ-PLAN)


    the build number. (i.e. 14)


    the full build key. (i.e. PRJ-PLAN-14)


    the fully expanded version name


    the version name as it was returned by Jira


    the version type keyword found (or blank)


    (true or false) if the version has been released in Jira

    Note that it's jiraversion and not jiraversions.
    This is because the variables represent the actual version returned from jira, and thus is labeled as "jiraversion".
    The other variables mentioned (jiraversions.jira.projectkey and others) are used internally by the plugin and thus "jiraversions" denotes that the variable belongs to the JiraVersions plugin.

    Hope that helps clear up the naming a bit.


    1. Hi, as I already mentioned the ONLY ${bamboo.buildKey} variable
      (from the above list) works.

      1. I talked with Ross, and since he's a bit busy I went ahead and fixed the issue.

        v1.0.3 should now expand all custom properties set outside of the tagger plugin.

         - Jonathan

  6. Hi,

    I have installed Bamboo Tagger Plugin and configured Tag Label as follows:


    Unknown macro: {ddmmyyyy}


    However, when I look at tag created in my CVS history in Eclipse, I will see this:


    I was wondering why I am getting 47 as month number instead of 9 which is the current month.

    I appreciate your help

    1. Hi Bahman, sorry about that...the plugin uses the formatting specified by the java SimpleDateFormat class. 'm' is actually minutes, whereas 'M' is months, so could you try change your label to be 'success_%d{ddMMyyyy}_%B?



      1. Hi Ross,

        Yes, that was the issue.

        Thank you, 


  7. Ok what am I doing wrong?

    I have tried every possible option that I can think of for tagging the build with the subversion revision number

    Tag Successful Build

    Tag = v8.3.${custom.svn.revision.number} or
    Tag = v8_3_${custom.svn.revision.number} or
    Tag = v8_3_${bamboo.buildNumber} or
    Tag = v8.3.${bamboo.buildNumber}

    What am I doing wrong.

    -Phillip Hancock


    1. It seems I had a older version of the jar. Not sure how I downloaded the wrong one

  8. Hi,

    Will it be possible to implement CVS tag command as well (not only rtag) ?



    1. Hi Andrei, apologies for not replying to you earlier, I didn't receive an email notification that a comment was made. I think adding an option to perform an CVS tag instead of a rtag command should be pretty straightforward, I'll let you know how I go.



    2. Hi again, I've just popped up version 1.0.5, which allows you to specify either 'tag' or 'rtag' for CVS plans. Let me know if there are any problems(smile)



  9. Bamboo Tagger doesn't play nice with our pre-commit hook which requires a valid issue key to be found. Instead of hardcoding this value

    com/atlassian/bamboo/plugin/tagger/svn/                    "Automatic copy from Bamboo");

    could we have it in some text input field so it enables custom commit messages (with e.g. a JIRA issue key).

    1. Hi Juha, yep, I can add a text field to hold the comment details, I'll let you know when I've put up a new version.



        1. Hi Juha, I've just popped up version 1.0.4, which now includes a field to specify the comment text. In addition, the plugin supports two additional replacement parameters: %J which includes the Jira issues and %C which includes the SCM comment information. These replacements apply to both the Tag Label and Comment Text.

          Let me know if there are any problems with the new version.



          1. I'm glad I didn't install the first update (smile) Now it works perfectly with 1.0.7, thanks!

  10. Version 1.0.5 is seriously broken - DONT install it - get version 1.0.4.

    Developers: Version 1.0.5 is broken on versions 2.0.6 and 2.1.3 of Bamboo (not tried the others). The problem appears when you try to edit a build plan after saving it - you get a nice stack trace.... not very useful if you want to actually edit the plan though (smile)

    1. Hi Gareth,

      The problem was related to the Ctrl-C and Ctrl-V keys (sad) Unfortunately there were two 'commentText' fields with the same name present in version 1.0.5, which had the effect of storing the commentText as an ArrayList, which caused the error. I've just released version 1.0.6 which only has the single comment text field.

      If users have not already upgraded to version 1.0.5 (and are not getting a ClassCastException when they try to edit the configuration, then you should be able to upgrade to version 1.0.6 without any problems.

      If however, you did upgrade to version 1.0.5, and you are getting a ClassCastException, then you will need to modify the build configuration manually. If you're using the internal Bamboo database, then there should be a <BAMBOO_HOME>/database/defaultdb.script file, inside this file there should be an insert statement containing the following: '<commentText>some text</commentText>\u000a<commentText>some text</commentText>\u000a'...if you modify this file such that there is only one 'commentText' element, then restart Bamboo, you should be able to edit your configuration again. If you're using another database provider, then you'll need to perform a similar modification using that specific database.

      My sincere apologies for any inconvenience, I'm in the process of updating the integration tests to ensure that this sort of error gets picked up. Please let me know via email at piaross at gmail dot com if you have any further problems.



  11. Hey,

    I've recently updated to bamboo 2.1.4 because of an issue with the build agents, anyway I've been trying to get the tagger to work.  I'm having no success.

    anyway after trawling through the logs I've found the following stack trace:

    INFO   | jvm 1    | 2008/12/05 03:19:37 | 2008-12-05 03:19:36,984 ERROR [pool-6-thread-1] [NamedThreadFactory] Uncaught exception in thread pool-6-thread-1
    INFO   | jvm 1    | 2008/12/05 03:19:37 | java.lang.NoSuchMethodError: org.tmatesoft.svn.core.wc.SVNCopyClient.doCopy(Lorg/tmatesoft/svn/core/SVNURL;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/SVNURL;ZLjava/lang/String;)Lorg/tmatesoft/svn/core/SVNCommitInfo;
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.svn.SubversionTagger.tagBuild(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.BuildTaggerAction.tagBuild(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.BuildTaggerAction.tagSuccessfulBuild(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at sun.reflect.DelegatingMethodAccessorImpl.invoke(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at java.lang.reflect.Method.invoke(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.orm.hibernate.HibernateInterceptor.invoke(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.orm.hibernate.HibernateInterceptor.invoke(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at $ Source)
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.event.DefaultEventManager$
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at$Worker.runTask(
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at$
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at$
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at$
    INFO   | jvm 1    | 2008/12/05 03:19:37 |       at

    any ideas?

    1. Hi Jerome, that's very strange, because as far as I can tell, the SubversionTagger class is invoking the correct method in the SVNCopyClient. I'll try to recompile things and I'll let you know how I go.



      1. Hi again, turns out that Bamboo 2.1.4 is using a later version of the SVNClient API. I've released version 1.1.0 of the plugin which should support Bamboo 2.1.4 (but not Bamboo 2.1.5 - there was additional API changes made, which version 1.2.0 of the plugin should support).



        1. Thanks for the quick reply, I'll give version 1.1.0 of the plugin a go

  12. Question with regard to Perforce Tagging: Does this only take the files in the clientspec? We have a clientspec here that contains multiple paths and it looks like the plugin only tagged the files in the first entry.

    Our clientspec looks something like this:
    //code/branch1/component1/... /clientspecname/component1/...
    //code/branch1/component2/... /clientspecname/component2/...

    but the label created by the plugin only tagged the first set of files and not the second.

    1. Hi David, I've popped a fix for this into version 1.2.1, let me know how it goes.



      1. Ok. I see the attempts in the bamboo server log but all of the label attempts after the first pair show these errors:

        2009-02-18 11:25:04,289 ERROR [pool-15-thread-1] [Depot] com.tek42.perforce.PerforceException:  Path '/proj/bamboo_agent/       //code/component/protocol/...' is not under client's root '/proj/bamboo_agent/xml-data/build-dir/TSTBUILD'.
        For Command: p4 -s tag -l     //code/component/protocol/...
        With Data:

        Now, maybe it is just my susceptiblity to choosing complicated build patterns but this has me confused. My setup has the Bamboo server on server1 with a remote agent running the build on server2 - maybe this is adding some complication where the clientspec/workspace is not mapping well on the Bamboo server. What I mean is that it appears to me that the tagging is occuring on the Bamboo server (server1) instead of the remote agent (server2) which may be the way that Bamboo does it's thing. What I can not understand is why Bamboo seems to be using a different clientspec/workspace? Maybe this is beyond the scope of the plugin and maybe it is a question for the Bamboo team?

        I made sure that both the Bamboo server and remote agent are operating in similar directories and allowing Bamboo to manage the workspace but maybe I am missing something simple. Here are some specifics to my Bamboo install:

        Client (Workspace): bamboo.test.linux.on_submit
        Depot View: //bamboo.test.linux.on_submit/...

        And my Perforce workspace/clientspec:

        Workpsace: bamboo.test.linux.on_submit
        Root: /proj/bamboo_agent/xml-data/build-dir/TSTBUILD-HCL
        View: //code/component/server/... /bamboo.test.linux.on_submit/server/...
        //code/component/protocol/... /bamboo.test.linux.on_submit/protocol/...

        1. After looking over the code and taking a look aat the perforce API, I think that the main focus of the problem may be in the way that saveToPerforce() executes it's work. Do you know of a Perforce or Bamboo API function that is exposted to us at the level of the saveToPerforce call that can describe for us (dump to the log) the current Bamboo/Perforce login information? This would be something akin to running the p4 info command on the command line.

          My line of reasoning here is that the first loop through the view list works and the 2..n of the loop fails with the above error. I am infering that saveToPerforce (or some other process) is losing access to the correct clientspec and all subsequent calls to saveToPerforce (2..n of the loop). These subsequent calls are using some default clientspec/workspace instead of the intended clientspec/workspace that is used for the first call.

          Just a thought. A co-worker and I are compiling the code locally but there is a learning curve for the Bamboo/Perforce API calls that we are at the bottom of.

          1. Hi David, you should be able to get a handle on the Depot instance which is available to the com.tek42.perforce.parse.Tag class - from there you can grab the username/password/etc. There's some info on the p4java library at

  13. Hi Ross,

    Great plugin, thanks.

    Can you modify the plugin to add output to the plan's build log?

    I see this message in the Bamboo server bamboo.log:
    2009-02-13 15:28:39,252 INFO pool-5-thread-1 SubversionTagger Successfully copied from svn+ssh:// to svn+ssh://

    It would be great if that could be added to the plan's build log, ie:
    Running post build plugin 'Bamboo Tagger'
    Successfully copied from svn+ssh:// to svn+ssh://

    Ideally, you'd log both successful tags as well as failures. It makes it easier for a build administrator to know if the tag was applied successfully.

    1. Hi Jeff, I've raised BTP-1 for this feature, I'll let you know once it's been included in a new release.



    2. Hi Jeff, this functionality should now be available in version 1.2.1.



  14. Ross, I'm using v1.2.1 of the tagger plugin with Bamboo v2.1.5 with a Build Plan that is using Perforce as SCM.  I don't know if this is a limitation of Bamboo itself, or a bug in the Tagger plugin, but I have discovered a behavior which, from my standpoint, makes the Tagger plugin unusable...  Here's the scenario:

    • Have a bash script - let's call the file '' - which is in Perforce and what the Build Plan sync and executes (via the Script Builder)
    • In '' have a 'sleep 60' call in there (works on my Mac, dunno about Linux).  This gives me 60 seconds to "do stuff" while the Build Plan is being executed.  (What's in the rest of the script doesn't matter -- I have just some echo comands, ensuring the build always succeeds.)
    • With '' stable at some revision (let's say it's revision 1 for this scenario), kick off the Build Plan
    • While the 'sleep 60' is occuring, check out, edit '' (doesn't matter what you put in it), and check it in.  It should be at revision 2 now.

    When the post-build step executes the tagging, what appears to be happening is that the revisions tagged are whatever is at the head revision at the time the tagging occurs -- i.e. NOT what the revisions where when the Build Plan kicked off (immediately after Bamboo is done "syncing to changelist <xyz>".

    In this case, when I examine the BAMBOOTEST-MAIN-1 label in Perforce and have it show me the files/revisions tagged, was tagged at #2, where it should be (IMO) at #1.

    With the situation as it is now, it is highly likely checkins can occur during the build (we have long build times for some projets), which makes the generated label useless to me as I cannot use it to re-sync to "what the build used".  (e.g. if a couple months down the road you need to re-generate the artifacts of an "old build" to re-supply to a customer), as the label as the "wrong versions".

    Any thoughts/comments/ideas?  I sure would like to avoid adding all the relevant P4 stuff directly into my build scripts if I can avoid it...



  15. That is an interesting problem that I did not consider before. Out dev shop uses Perforce pretty extensively and I can see how this could occur.

    The problem is that Bamboo does not check out the code to do a build but syncs to the head revision and assumes that a subsequent build will capture the change. If the code is changed while it is building then it is natural for Bamboo, as a CI build tool (continuous integratio), to function this way.

    When it comes to the Tagger, I think that it may not be possible to capture this event - due to the nature of the bamboo build cycle.My first inclination is to try locking the Perforce branch from allowing check-ins during the Bamboo exection. I do not think that is something that the Bamboo team would be interested in implementing as it ties up the code line during the build. It may be possible to use pre/post build steps to lock the code line - when that is the behaviour that you would require from Bamboo - thus allowing the Tagger to function as intended.

    Outside of that I can not think of a Perforce mechanism that would help. I will run it by out Perforce guys in the morning and see if there is another solution. I am interested as we are looking to use Bamboo as the build portion of a release management system.

    It may be of interest to take a look at the Jira Version plugin. They would run into this same issue.

    1. Locking the files in Perforce would definitely not be any better a situation than the current problem – especially if you have long build times.

      If you watch the Activity page for a Build Plan as it's executing, you can see a message like "Syncing code to revision <xyz>" – theoretically the "Retrieve Source" step in the diagram on the Bamboo Plugin Guide. If a new metadata key/value were simply stored as to what that revision is, it should be possible to have a (tagger) plugin consume it appropriately. I'll have to noodle a bit on the Perforce commands you'd have to use to ensure you tag the correct file revisions given a changelist number, but I'm pretty sure it's doable. It might not be a single command that tags an entire viewspec contents – you might have to get per-file revisions that correlate to the changelist that Bamboo synced to, but I can't imagine it's impossible.

      For example:

      • p4 -p localhost:1666 changes -i -m 1 (get the most recent submitted changelist - this is probably what Bamboo does to determine what to sync). In my example case, I get this:
        Change 11 on 2009/03/10 by davidaldridge@daldridgembp 'Blah '
      • p4 -p localhost:1666 describe 11 (describe the particular changelist in detail). In my case, I get this:
        Change 11 by davidaldridge@daldridgembp on 2009/03/10 18:07:04
        Affected files ...
        ... //BambooTest/Ignore.txt#2 edit
        <diffs follow, we don't care>
      • p4 -p localhost:1666 -c daldridgembp files //daldridgembp/Development/BambooTest/...@2009/03/10:18:07:04 (List the revision of all files that the build plan synced, specified by that particular changelist's timestamp and appropriate clientspec). Note that this is only needed if the plugin would need to do per-file processing (I don't think it does...). I get:
        //BambooTest/ - edit change 6 (xtext)
        //BambooTest/Ignore.txt#2 - edit change 11 (text)
      • p4 -p localhost:1666 -c daldridgembp tag -l BAMBOOTEST-MAIN-8 //daldridgembp/Development/BambooTest/...@2009/03/10:18:07:04 (Tag all the files in the given depot location, at the revisions corresponding to the given timestamp)
        //BambooTest/ - added
        //BambooTest/Ignore.txt#2 - added

      Voila. Piece of cake (smile) This obviously assumes that the tagger plugin could fetch the changelist number from the metadata, along with the "Depot View" value in the Builder setup portion of the Build Plan (in my example, //daldridgembp/Development/BambooTest/...).

      In my opinion, I don't think it matters that the changes will be caught in the next round of Build Plan execution in the CI setup. All I want is correct behavior for the Build Plan cycle currently executing.

      1. Hi David, the tagger plugin uses the p4java library to perform the Perforce operations. I don't think there would be any dramas with issues several p4 calls, and I think the plugin should be able to incorporate any commands that you can execute on the command line. Feel free to have a hack at the plugin source code to get it working the way you think it should(smile)



        1. I think I'll do that (smile) Assuming I can get it to work (might have to hack Bamboo itself if that "synced changelist number" isn't available, and that might be deeper water than I care to wade into), I'll add a Feature Request/Improvement to the BTP JIRA database with the modified files for you.

          1. Another option that came to mind (and I admit that I am not necessarily a fan of the option because it is a brute-force method to get the result) was to use p4 fstat to obtain the revisions that are contained in the build environment (bamboo build area through the clientspec) and label only those revisions.

          2. Ross, I have source code changes that accomplish my goals as stated in this discussion thread (tag files at the changelist to which the Build Plan syncs, rather than head revisions at the time of tagging). It was essentially 3 easy one-liner changes to the perforce Tag, TagBuilder, and PerforceTagger classes. However, it doesn't appear that anonymous SVN commits are allowed, and I have no idea how to create an account, what the review policies are, etc.. Do you have recommendations on how I should submit these changes?

            1. Hi David, you could either send the changes to me, or email Jonathan Nolen, and he can set you up with the access to the Subversion repository.



      2. Does it not also assume that there is only one change list that is being built at a given time?

        1. I'm not following you?

          It's my understanding that there is only one change list being built - per Build Plan execution (it's not correct to say "at once" if you have a remote agent setup allowing you to do parallel builds). However, even if you had multiple Build Plans pointing to the same depot location, the Build Plans are executed independently (serially or parallel depending on your remote agents setup), and each Build Plan executes a single linear process of sync/build/collect. You only sync once at the beginning of each Build Plan execution.

          What am I missing?

          1. Sorry. no I think you are on the right track. I re-read the posts and I agree.

  16. Hi

    Thanks for a great plugin!

    I have several build plans. Some use the Jira Version plugin and the Tagger to tag Subversion with the Jira version number. Works fine. However some of the build plans are for projects that are not in Jira. The version number is set in the project's Ant build.xml. Is it possible to "communicate" this version number out to Bamboo and the Tagger plugin?

    1. Hi Stefan, hmmm, retrieving information out of a property set by Ant might be tricky, as I don't think it's straightforward to set environment variables in Ant. Could you send me a mail at piaross at gmail dot com outlining how the build process works, and I'll see if I can come with a solution?



  17. hi

    i have updated to the new Bamboo 2.2 and it's seems like the plugin is not working

    iam using the 1.0.8 and update to the 1.2.1 when i update to bamboo 2.2

    and after the plan completed successfull, no new tag appear in the SVN repositories.

    is ther any new version compatible with bamboo 2.2

    1. Hi, I've just released version 1.3.0 which should now support Bamboo 2.2.



      1. hi Ross

        thanks, it's working now with the new version

  18. Hi Ross,
    It looks like version 1.3.0 of the plugin is not resolving custom metadata that we have set.  This was working in prior versions.  I have verified that using standard Bamboo variables works.  For example, if Tag Label = ${bamboo.buildKey}, the value is resolved.  We set custom metadata that I know is being set because it is visible in the Metadata tab in the Bamboo build result.
    Entry from build log on Bambo 2.1.5:
    atlassian-bamboo.log.1:2009-03-20 03:28:23,866 INFO [pool-8-thread-1] [SubversionTagger] Successfully copied 
    from svn+ssh:// to svn+ssh://
    Entry from build log on Bambo 2.2:
    2009-03-24 10:11:37,625 ERROR [pool-19-thread-1] [SubversionTagger] org.tmatesoft.svn.core.SVNException: 
    svn: Path tags/${bamboo.WD_VERSION}/trunk' already exists
    1. Hi Jeff, I'll take a look at this asap and let you know.



    2. Hi Jeff, how have you set the custom metadata? I just tested setting a global variable (via 'Administration' - 'Build Resources' - 'Global Variables') and referred to it in the build tag, and the variable replacement seemed to work okay.



      1. Hi Ross,

        Thanks for the quick feedback. Your question got me thinking it might be something on my end. We have a custom plugin that we wrote that uses the
        Bamboo API to add all values from a properties file as Bamboo metadata. Let me try recompiling it against Bamboo 2.2 to see if that solves the problem.


        1. Recompiled our plugin and the problem is still occurring. We set metadata in a plugin using this call:

          buildContext.getBuildResult().getCustomBuildData().put(key, value);

          1. Hi Jeff, I think this might be due to a bug with Bamboo 2.2. In Bamboo 2.1.x, the Tagger plugin invoked

            variableSubstitutionBean.substituteBambooVariables(modifiedString, build.getBuildKey(), 
                         build.getBuildLogger(), buildResult.getBuildResultsSummary().getCustomBuildData());

            With Bamboo 2.2, the plugin must now invoke the following:

            	     modifiedString, buildResult, build.getBuildLogger());

            Now, the customBuildData that your plugin creates is available from buildResult.getBuildResultsSummary().getCustomBuildData(), however the class (which the Tagger plugin uses) is instead populating the variable map using buildResults.getCustomBuildData(), which does not contain the custom variables.

            I think the getVariables() method of should be updated to also include the variables contained in the buildResult.getBuildResultsSummary().getCustomBuildData()'ll probably need to raise a support request to get this actioned.



  19. hi, First of all thanks for a great plugin!
    Unfortunately I've just broken it by upgrading from Bamboo 2.2. to 2.4.0 (sad)
    Are there any plans to support Bamboo 2.4.0 ?


    1. Hi Trevor, sorry about that, I'll take a look at getting the plugin compatible with Bamboo 2.4 now.



      1. Looking good now, thanks Ross!


  20. Ross,

    Do you want to do it, or do you want me to continue OSGi-ifying it and adding pluggable taggers?

    - Jonathan

    1. Hi Jonathan, thanks, but I've just released a new version which should support Bamboo 2.4

      1. Cool, so at this point the trunk is stable with 2.4 compatibility and I can re-factor for osgi and pluggable taggers?

        Just asking since the bamboo-jira-versions plugin is stuck being a V1 plugin until the tagger plugin is updated.


        - Jonathan

        1. Yep, you should be right to do your refactoring now.