Checkout conflict with release-finish

[RonanL]

Hi all,

As I mentioned in a previous post, my team is making a transition to git/maven/jenkins/gitflow, and I am looking at leveraging jgitflow. The goal is to create a small number of jobs in jenkins which make use of jgitflow for creating release branches and then doing the required tasks when the release is ready to ship to production (merges, updating of poms etc).

So, from what I've read, I should be able to use the jgitflow release-start and release-finish goals to achieve this. The release-start appears to be working well for me, I have a jenkins job which does the following:

jgitflow:release-start -X -DreleaseVersion=$RELEASE_VERSION

This works well, and I can see the new release branch is created, using the version passed as a parameter to the job.

However, when I call release finish I am getting an error. The jenkins job which calls release finish first runs the following shell commands:

cd $WORKSPACE; pwd; git checkout release/$RELEASE_VERSION; git pull

and the maven call is as follows:

jgitflow:release-finish -X -DreleaseVersion=$RELEASE_VERSION -DdevelopmentVersion=$DEVELOPMENT_VERSION -DnoDeploy=true -DnoTag=true

The job fails, with the following error:

[ERROR] Failed to execute goal com.atlassian.maven.plugins:maven-jgitflow-plugin:1.0-alpha27:release-finish (default-cli) on project xxxxxxxxx: Error finishing release: Error releasing: org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:
[ERROR] app/pom.xml

When I run a git status from the command line on the server doing the jenkins work, I see the following:

On branch master
Your branch is up-to-date with 'origin/master'.

You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      app/pom.xml

no changes added to commit (use "git add" and/or "git commit -a")

And when I vi the pom, I see the following:

  5 <<<<<<< HEAD
  6         <version>1.1.0</version>
  7 =======
  8         <version>1.3.0</version>
  9 >>>>>>> refs/heads/release/1.3.0

Any pointers on what I'm doing wrong? I'm keen to make use of the plugin, so it would be great if someone could point me in the right direction.

Thanks,

Ronan

[Jonathan Doklovic]

You're using a really old version of the plugin.

Please upgrade to the latest version and see if your issues go away.

[RonanL]

Thanks Jonathan.

I updated to 1.0-m3 which is the most recent available to me.

Having updated my pom (and changing nothing else), I now get an error when I call release-start. The error is below. Any thoughts?

[INFO] ensuring origin exists...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.679s
[INFO] Finished at: Thu Aug 28 06:56:59 EDT 2014
[INFO] Final Memory: 21M/1962M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m3:release-start (default-cli) on project xxxxxxx: Error starting release: Error setting origin in configuration: NullPointerException -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m3:release-start (default-cli) on project ap102643-time-and-sales: Error starting release: Error setting origin in configuration
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error starting release: Error setting origin in configuration
	at com.atlassian.maven.plugins.jgitflow.mojo.ReleaseStartMojo.execute(ReleaseStartMojo.java:97)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 19 more
Caused by: com.atlassian.maven.plugins.jgitflow.exception.MavenJGitFlowException: Error setting origin in configuration
	at com.atlassian.maven.plugins.jgitflow.manager.tasks.SetupOriginAndFetchIfNeeded.run(SetupOriginAndFetchIfNeeded.java:47)
	at com.atlassian.maven.plugins.jgitflow.manager.AbstractFlowReleaseManager.runPreflight(AbstractFlowReleaseManager.java:73)
	at com.atlassian.maven.plugins.jgitflow.manager.AbstractProductionBranchManager.getStartLabelAndRunPreflight(AbstractProductionBranchManager.java:50)
	at com.atlassian.maven.plugins.jgitflow.manager.DefaultFlowReleaseManager.start(DefaultFlowReleaseManager.java:45)
	at com.atlassian.maven.plugins.jgitflow.mojo.ReleaseStartMojo.execute(ReleaseStartMojo.java:93)
	... 21 more
Caused by: java.lang.NullPointerException
	at org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:481)
	at org.eclipse.jgit.transport.TransportHttp.openFetch(TransportHttp.java:306)
	at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
	at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
	at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1111)
	at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:130)
	at com.atlassian.maven.plugins.jgitflow.manager.tasks.SetupOriginAndFetchIfNeeded.run(SetupOriginAndFetchIfNeeded.java:42)
	... 25 more

[RonanL]

Update: I got the m4 version and that returns the same error as m3. Then I reverted to the alpha27 version I had been using previously, and the release-start goal ran successfully (release branch created), but I already know that version won't work when I try to do release-finish.

Any thoughts?

Thanks,

Ronan

[Luke Jackson]

Hi Ronan

I've had this stack trace before - it was a couple of months ago so I have forgotten exactly how I fixed it, but the NPE is related to a null CredentialsProvider in jgit.  Given you are using an HTTP url, I would suggest checking you are providing a username and password.

Luke

[RonanL]

Thanks Luke.

I'll definitely look into that, but can you elaborate on the following: "Given you are using an HTTP url I would suggest checking you are providing a username and password.". Excuse the basic question but where are those typically specified? I have credentials specified in my jenkins job, but those are related to the git repository so I'm not sure if those are used by maven/jgitflow? I'm also confused as to why this works with the old version but doesn't now!

Thanks again for the reply.

[Jonathan Doklovic]

<defaultOriginUrl> in your pom is where you set it.

Also, you can add <alwaysUpdateOrigin> to true to help if you have a CI server that likes to mess with your origin url.

[RonanL]

I've added defaultOriginUrl and lwaysUpdateOrigin as suggested, and I also added the username and password arguments to the maven call, but I'm still seeing errors. Different versions of the plugin result in different errors at different points, but I'm still no closer to finding a configuration that works for release-start and release-finish.

Jonathan, I've asked the team who run our ALM tools to open a ticket with Atlassian for additional support, so perhaps that will find it's way to you or your team.

In the meantime, if anyone has any additional suggestions here, I'm all ears.

Thanks,

Ronan

[Jonathan Doklovic]

Hey Ronan,

It will be faster if you just log an issue here: https://ecosystem.atlassian.net/browse/MJF

If you make a support request through support.atlassian or whatever, they're just going to hunt me down and ultimately log an issue in the tracker above. It's faster if you just bypass the middleman in this case.

When you log the issue, please provide the full stack trace and attach your <project dir>/.git/jgitflow.log file.

Let's stick with the information for 1.0-m3 as we're not going to hotfix any previous releases at this point.

Thanks,

- Jonathan

[RonanL]

Thanks Jonathan.

Issue created as requested: https://ecosystem.atlassian.net/browse/MJF-187

I couldn't attach a jgitflow log for this example because it's not being created.

Ronan

[Jonathan Doklovic]

Hmmm. Strang that there's no jgitflow.log.

Can you please attach your .git/config file to the issue?

--
You received this message because you are subscribed to the Google Groups "Maven JGit Flow Plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to maven-jgitflow-u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[RonanL]

Issue updated with .git/config as requested.

Thanks,

Ronan

[RonanL]

Is there any other information that I can provide that might help towards getting a resolution?

Thanks,

Ronan

[RonanL]

Hi again,

I hope I'm not going to confuse things too much here, but at this point it appears I've got two issues with using the jgitflow plugin. I believe both can be overcome through configuration, but I need help with that.

1. NPE on release-start (https://ecosystem.atlassian.net/browse/MJF-187)
1. I just ran this goal successfully from my laptop (git bash command line) where I am configured to use ssh. This is further evidence that the issue I'm seeing with the same goal running via my jenkins job is related to credentials. I'd appreciate if someone could point me towards the places I'd need to make changes to use ssh instead of https from my jenkins server. I'm guessing pom changes to the <scm> element, and set enablesshagent to true in the jgitflow configuration?
2. Merge conflict on release finish
1. This is the issue I started this email with, and it remains even when I run the goal from my laptop using git bash, which rules out the credential issue being at the root of this one. It's clear the failure is occurring with the commit of the updated pom version, but the question is why. Having googled the issue I saw some talk of end-of-line characters. Is there a setting I can use to get past this?

Thanks,

Ronan

PS: I forgot to mention before now that the GIT software we're using is Stash - not sure if that's relevant.

[Luke Jackson]

Hi Ronan

For (1) My understanding is that jgitflow will use ssh if this is how the origin URL is set up in the cloned git repo. Since Jenkins is likely cloning the repo, it is something you'd need to configure there.

Bamboo, for example, doesn't always set the origin when cloning, if this is the case with Jenkins you can set defaultOriginUrl in the plugin config, which the plugin will use if (and I believe only if) one is missing.

Jgitflow does not use the scm settings in your Pom. 

To get ssh authentication working with Stash, I followed these steps:

1. Ensure build user on each build agent had an ssh public/private key pair generated.

2. Create a build user in Stash, if not already. 

3. Ensure this user has read/write permissions on the repos it will be managing. 

4. Log in to Stash as that build user and upload the ssh public keys from each build agent in the user profile page.

5. (Optional) test the connection from the build agents manually, adding the Stash host to the list of known hosts when prompted.

I don't use the ssh agent property, but from Jonathan's YouTube video it seems he uses this to create and configure the ssh key automatically on each connection.

For (2) I've not come across this issue before, but you can look into the core.autocrlf git attribute to normalise line endings. 

Regards

Luke

[RonanL]

Thanks Luke.

I got the the bottom of the SSH issue - the service account we created needed to be given branch access through the Stash repository settings menu. Despite the user already having read/write on the repo in general. I only realised when I did all the steps outlined by you above, and I tried doing a push from the command line on the jenkins slave, which failed, with an error. Unfortunately the jgitflow plugin absorbed the error and proclaimed success despite the pushes failing during the release-start call.

I've moved on to the release-finish issue. I need to do some reading on the line feed thing - that might not even be the cause.

Thanks again,

Ronan

[Luke Jackson]

Good to hear you got your first problem solved. I've been tripped up by the silent failure to push as well, thanks for raising a JIRA for that. 

The plugin is great once you get it working, it has made our release procedure so much simpler that before.

Luke