tm1701
tm1701

Reputation: 7601

maven release plugin for simple git project - error: not a working copy

How can I perform 'releasing' on a simple project using the Maven 'maven-release-plugin' while using with Git(lab)?

I am working on a dev / feature branch and finally I merge the updates into the 'master' branch. I guess, then the 'release' plugin comes into play. Correct?

In my Jenkinsfile I call:

sh 'mvn release:prepare release:perform'

While trying many options, I keep getting this error:

The svn command failed. 
[ERROR] Command output:
[ERROR] svn: E155007: '..workspace/project/pom.xml' is not a working copy

The command that fails is:

[INFO] Executing: /bin/sh -c cd /var/jenkins_home/workspace/jenkins-testing-releasing && svn --non-interactive commit --file /tmp/maven-scm-1557766606.commit --targets /tmp/maven-scm-8208798121252708517-targets
[INFO] Working directory: /var/jenkins_home/workspace/jenkins-testing-releasing

Strange, because I don't work with SVN.

This is what I have so far:

<project ...
    <artifactId>jenkinstesting</artifactId>
    <version>0.1-SNAPSHOT</version>
    <scm>
        <connection>scm:git:[email protected]:user/project.git</connection>
        <developerConnection>scm:git:[email protected]:user/project.git</developerConnection>
        <tag>rel1</tag>
    </scm>

Version 1:

    <build>
        <plugins ... 
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.2.1</version>
                <executions>
                    <execution>
                        <id>default</id>
                        <goals>
                            <goal>perform</goal>
                        </goals>
                        <configuration>
                            <pomFileName>pom.xml</pomFileName>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Version 2:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.1</version>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.5.3</version>
</plugin>

Upvotes: 4

Views: 1306

Answers (1)

tm1701
tm1701

Reputation: 7601

As suggested in some posts, it is (indeed) better to use the Jgitflow Maven plugin. Even the project changed to this plugin. So, there was no reason to stick to the Maven Release plugin. Looking back, I finally agree with the advice and move forward with the Jgitflow plugin.

What are the results of the release step? Suppose the current version of the development branch is 0.5.0-SNAPSHOT.

  • We have a 'release' branch with the right version and built products (v0.5.0);
  • We have a 'development' branch ready for the next release (v0.6.0-SNAPSHOT);
  • We have a 'master' branch as a backup (v0.5.0).

Which actions are required?

  • Create a new 'release' branch based on the development branch. The version of this branch is the current version minus the '-SNAPSHOT' part.
  • Build the endproducts with that release branch. You can also build Docker images with a tag with that version. You can add other labels to that Docker image.
  • Merge the branch into the 'master'branch. So you have a backup for production issues.
  • Determine the number of the next version of the 'development' branch. This depends on whether you want a major, minor or patch release.
  • Update the 'development' branch with the new version.

OK, show me the code ... ;-)

def mavenHome = tool 'Maven Latest'
def nextVersion = // determine this on the requested major/minor/patch release
sh "${mavenHome}/bin/mvn clean -B jgitflow:release-start jgitflow:release-finish " +
        "-DskipTests " +
        "-DallowUntracked=true " +
        "-DpushReleases=true " +
        "-DscmCommentPrefix=[RELEASE]- " +
        "-DenableSshAgent=true " +
        "-DreleaseVersion=${nextVersion}"

The determining of the next version could take as an argument: major, minor or patch, etc.

The preparation is: When working with GIT-flow, you could merge your feature branch changes into the development branch via a pull request.

Upvotes: 1

Related Questions