Maven jgitflow plugin

Question

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.

score 1 · Accepted Answer · edited May 23 '17 at 12:31

1

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.

edited May 23 '17 at 12:31

Community

1
1

answered Jan 19 '16 at 13:20

A_Di-Matteo

26,902
7
94
128

After setting the local branch to checkout from as 'origin/develop' I get the following error: `error occurred during unpacking on the remote end: unpack-objects abnormal exit` – edmond Jan 19 '16 at 16:04
@edmond sounds like directory permissions configuration, can you check that? – A_Di-Matteo Jan 19 '16 at 16:06
Upon setting the permissions I am now getting "short read of block" as error. – edmond Feb 23 '16 at 08:08
Hi @A. Di Matteo. how should the permissions configuration look like? Thanks – edmond Feb 23 '16 at 15:44
@edmond permissions about the read/write on the concerned folders, did you check [this](http://stackoverflow.com/questions/17187528/git-configuration-with-eclipse-not-able-to-push-code-from-eclipse-to-remote-git) and [this](http://stackoverflow.com/questions/5898042/egit-push-operation-giving-error-error-occurred-during-unpacking-the-remote-en) threads? – A_Di-Matteo Feb 24 '16 at 13:14
1

Hi @A. Di Matteo. The problem was really the permissions. I had created the git project on my local machine and copied it on the server with scp. Even changing the permissions afterwareds did not help. To solve the issue, I created the .git repository on the server itself. Doing so gave the group of the folder the same permissions as the owner. – edmond Feb 25 '16 at 09:51
@edmon great, what do you prefer? I update the answer accordingly with the history of these comments or you prefer to post another answer? So that the question doesn't remain unanswered – A_Di-Matteo Feb 25 '16 at 10:13
I prefer the first option. I mean updating the answer. Thanks – edmond Feb 25 '16 at 14:54

score 0 · Answer 2 · answered Oct 31 '18 at 13:07

A little timesaver for all the folks working with GitLab and experiencing this problem:

GitLab's Runner works on a DETACHED HEAD, which causes JGitFlow's search for GIT refs to fail, resulting in exactly this error.

The solution is as it is for Jenkins: before performing the JGitFlow operation, make a checkout. For GitLab you can do this by adding a git checkout in the /script part of the respective pipeline your gitlab-ci.yml, for example:

sample-pipeline:
   stage: release
   script: 
   -git checkout -B master
   -mvn --batch-mode jgitflow:release-start jgitflow:release-finish

Since JGitFlow automatically checks out the develop branch and does its magic from there, you can always check out the master beforehand, as it has no effect at all; its just important that its not a DETACHED HEAD when GitLab starts its search for refs.

Maven jgitflow plugin

2 Answers2