CODEWITHSUNDEEP
mavensvnreleasebamboo
PBeaumont
PBeaumont

Reputation: 11

Superfluous trunk subfolder created in SVN tag when releasing with Maven from Bamboo

We have run into this issue a couple of time:

Instead of containing a version of the trunk modified for release, the tagged folder contains a copy of the trunk before any modification, and it also contains a 'trunk' subfolder where the correct modified version is.

Therefore, if I have this in my SVN repo before releasing:

Normally, I would have the following after releasing version 1.0.0:

However, very few times, I wound up with:

The 'scm' tag in the pom.xml before releasing seems correct, so I don't think if comes from there:

<scm>
  <url>http://.../projectName/trunk</url>
  <connection>scm:svn:http://.../projectName/trunk</connection>
  <developerConnection>scm:svn:http://.../projectName/trunk</developerConnection>
</scm>

My Bamboo plan is composed of the following tasks:

  1. Source Code Checkout (with Force Clean Build)
  2. Script (to determine the release version)
  3. Maven 3.x (Actual release)

My Maven 3.x task has the following goal:

--batch-mode -Dusername=${bamboo.username} -Dpassword=${bamboo.password} -Dtag=${bamboo.version} release:prepare -DreleaseVersion=${bamboo.version} -DdevelopmentVersion=${bamboo.nextVersion}-SNAPSHOT -Dresume=false release:perform

The plugin has no options:

<plugin>
  <artifactId>maven-release-plugin</artifactId>
  <version>2.4.1</version>
</plugin>

Having checked in the logs, I cannot see anything abnormal to determine the cause. 

[LOG] Checking in modified POMs...
[LOG] Executing: /bin/sh -c cd .../build-dir/PROJECT-PLAN-JOB && svn --username user --password '*****' --no-auth-cache --non-interactive commit --file .../temp/PROJECT-PLAN-JOB/maven-scm-386932260.commit --targets .../temp/PROJECT-PLAN-JOB/maven-scm-7155492065832691877-targets
[LOG] Working directory: .../build-dir/PROJECT-PLAN-JOB
[LOG] Tagging release with the label 1.0.0...
[LOG] Executing: /bin/sh -c cd .../build-dir/PROJECT-PLAN-JOB && svn --username user --password '*****' --no-auth-cache --non-interactive copy --file .../temp/PROJECT-PLAN-JOB/maven-scm-80256020.commit --revision 46345 http://.../projectName/trunk http://.../projectName/tags/1.0.0
[LOG] Working directory: .../build-dir/PROJECT-PLAN-JOB
[LOG] Transforming 'projectName'...
[LOG] Not removing release POMs
[LOG] Checking in modified POMs...
[LOG] Executing: /bin/sh -c cd .../build-dir/PROJECT-PLAN-JOB && svn --username user --password '*****' --no-auth-cache --non-interactive commit --file .../temp/PROJECT-PLAN-JOB/maven-scm-1254735614.commit --targets .../temp/PROJECT-PLAN-JOB/maven-scm-2179675177497779390-targets
[LOG] Working directory: .../build-dir/PROJECT-PLAN-JOB
[LOG] Release preparation complete.
[LOG] 
[LOG] --- maven-release-plugin:2.4.1:perform (default-cli) @ projectName ---
[LOG] Checking out the project to perform the release ...
[LOG] Executing: /bin/sh -c cd .../build-dir/PROJECT-PLAN-JOB/target && svn --username user --password '*****' --no-auth-cache --non-interactive checkout http://.../projectName/tags/1.0.0 .../build-dir/PROJECT-PLAN-JOB/target/checkout
[LOG] Working directory: .../build-dir/PROJECT-PLAN-JOB/target
[LOG] Invoking perform goals in directory .../build-dir/PROJECT-PLAN-JOB/target/checkout
[LOG] Executing goals 'deploy'...

From what is see in the log, the execution is:

  1. The version in the pom is modified to remove the -SNAPSHOT (1.0.0)
  2. This pom is commited in the trunk
  3. The content of the trunk is copied into the tag 1.0.0
  4. The version in the pom is modified to next version (1.1.0-SNAPSHOT)
  5. This pom is commited in the trunk
  6. The content of the tag 1.0.0 is checked out in the folder /target/checkout/
  7. The release is done on the /target/checkout/

Any idea why the 1.0.0 tag folder in the SVN repo contains another 'trunk' subfolder there?

Upvotes: 0

Views: 111

Answers (1)

PBeaumont
PBeaumont

Reputation: 11

After investigation, I have found that this happens because of the maven-release-plugin and has nothing to do with Bamboo. In fact, as soon as you try to release a version that has already been released, this is what will happen.

This is the "normal" behavior of the plugin.

Upvotes: 1

Related Questions