Search code examples
mavenjenkinshudsonjgitflow-maven-plugin

Maven jgitflow plugin


I don't know if any of you do use the maven plugin jgitflow. when running

clean jgitflow:release-start jgitflow:release-finish

on hudson, I get the following error:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start (default-cli) on project test-git-release: Execution default-cli of goal external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start failed: String index out of range: -6

My pom.xml looks as follows:

<plugin>
 <groupid>external.atlassian.jgitflow</groupid>
 <artifactid>jgitflow-maven-plugin</artifactid>
 <version>1.0-m5.1</version>
  <configuration>
   <enablesshagent>true</enablesshagent>
   <defaultoriginurl>URL</defaultoriginurl> 
   <autoversionsubmodules>true</autoversionsubmodules>  
   <nodeploy>true</nodeploy>    
   <pushreleases>true</pushreleases>
    <flowinitcontext>
     <versiontagprefix>V_</versiontagprefix>
    </flowinitcontext>
 </configuration>
</plugin>

On my local machine I am able to run this command successfully.


Solution

  • Apparently is a known bug: official bug report, for the same version you mentioned and same behavior (working fine locally but same exception on Jenkins/Hudson).

    Note that the linked bug report above provides a workaround maybe worth to try:

    The workaround is in Jenkins: Additional Behaviours => checkout to specific local branch


    Update
    According to the comments exchanged, proposed solutions and effective resolutions, here is the historical log for future helps:

    • Following the suggested workaround above and setting the local branch to checkout from origin/develop, the following error was encountered:
      error occurred during unpacking on the remote end: unpack-objects abnormal exit
    • Such an error was actually due to permissions on the concerned folder, as also suggested by other SO threads, here and here. However changing the permissions afterwards did not help.
    • The issue was finally solved by creating the .git repository on the server itself. Doing so gave the group of the folder the same permissions as the owner.