Bamboo Tagger plugin

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: http://docs.atlassian.com/atlassian-bamboo/2.0/com/atlassian/bamboo/build/AbstractSubstitutionBean.html

Cheers,
Edwin

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://svn.foo.test/bar/tags/

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?

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

    getSvnClientManager(svnRepository).getCopyClient().doCopy(
        SVNURL.parseURIDecoded(svnRepository.getRepositoryUrl()),

        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?

Hi Ross,

It would be nice to support JiraVersions variables such as bamboo.custom.jiraversion.name, 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?

Thanks 

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.:

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.

-Jonathan

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

or

Hi,

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

Thanks,

Andrei.

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/SubversionTagger.java:                    "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).

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

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(SubversionTagger.java:96)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.BuildTaggerAction.tagBuild(BuildTaggerAction.java:142)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.BuildTaggerAction.tagSuccessfulBuild(BuildTaggerAction.java:124)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.plugin.tagger.BuildTaggerAction.run(BuildTaggerAction.java:73)
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(DelegatingMethodAccessorImpl.java:25)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at java.lang.reflect.Method.invoke(Method.java:597)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:304)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:117)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.orm.hibernate.HibernateInterceptor.invoke(HibernateInterceptor.java:117)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at $Proxy42.run(Unknown Source)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.v2.build.events.PostBuildCompletedEventListener.performCustomBuildCompleteAction(PostBuildCompletedEventListener.java:68)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.v2.build.events.PostBuildCompletedEventListener.handleEvent(PostBuildCompletedEventListener.java:41)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.event.DefaultEventManager$2.run(DefaultEventManager.java:202)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at com.atlassian.bamboo.build.pipeline.concurrent.NamedThreadFactory$1.run(NamedThreadFactory.java:32)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at edu.emory.mathcs.backport.java.util.concurrent.helpers.ThreadHelpers$1.run(ThreadHelpers.java:34)
INFO   | jvm 1    | 2008/12/05 03:19:37 |       at java.lang.Thread.run(Thread.java:619)

any ideas?

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.

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://10.0.0.20/usr/local/repos/myrepos/trunk to svn+ssh://10.0.0.20/usr/local/repos/myrepos/tags

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://10.0.0.20/usr/local/repos/myrepos/trunk to svn+ssh://10.0.0.20/usr/local/repos/myrepos/tags/mytag

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.

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 'TaggerTest.sh' - which is in Perforce and what the Build Plan sync and executes (via the Script Builder)
• In 'TaggerTest.sh' 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 'TaggerTest.sh' 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 'TaggerTest.sh' (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, TaggerTest.sh 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...

Cheers,

David

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.

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?

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

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
Are there any plans to support Bamboo 2.4.0 ?

Cheers,
Trevor

Ross,

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

- Jonathan