gitflow releases with maven?

Discussion:

Lars Fischer

2011-07-25 13:31:30 UTC

Hello,

I use git together with gitflow(1) and would like to release projects the
gitflow way. Gitflow itself creates branches, a release tag and merges
changes back into other branches.

The maven-release-plugin performs similar things an other way. I tried to
use both together, but it works only with hacks and results in confusing or
not correct tags.

Is there a kind of "lightweight" release-plugin, which does only perform
- version-checks and updates (remove SNAPSHOTs)
- build and test the changed project
- commit the changes into the current branch if everything is correct

It should NOT create a tag or push changes.

[1] http://nvie.com/posts/a-successful-git-branching-model/
http://yakiloo.com/getting-started-git-flow/

Regards,
Lars

Mark Derricutt

2011-07-25 20:16:02 UTC

Permalink

We're using gitflow/maven quite nicely, I use for my release plugin:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<goals>deploy</goals>
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
</configuration>
</plugin>

In this configuration maven does a local checkout, and doesn't require a git push during release. This means after a maven release, I do my git-flow release, THEN push the master/develop branch to my origin.

In my default setup, if I want to push the tags I still have to run "git push --tags", but I also get the opportunity to remove any tags I don't want to push.

Post by Lars Fischer
Hello,
I use git together with gitflow(1) and would like to release projects the
gitflow way. Gitflow itself creates branches, a release tag and merges
changes back into other branches.
The maven-release-plugin performs similar things an other way. I tried to
use both together, but it works only with hacks and results in confusing or
not correct tags.
Is there a kind of "lightweight" release-plugin, which does only perform
- version-checks and updates (remove SNAPSHOTs)
- build and test the changed project
- commit the changes into the current branch if everything is correct
It should NOT create a tag or push changes.
[1] http://nvie.com/posts/a-successful-git-branching-model/
http://yakiloo.com/getting-started-git-flow/
Regards,
Lars

Lars Fischer

2011-07-26 07:30:16 UTC

Permalink

Hello Mark,

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<goals>deploy</goals>
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
</configuration>
</plugin>
In this configuration maven does a local checkout, and doesn't require a git push during release.
This means after a maven release, I do my git-flow release, THEN push the master/develop branch to my origin.

I'm sorry, I don't understand. You first run the maven-release-plugin?
On which gitflow-branch (develop, feature, release)?

I think the maven release results in a NON-SNAPSHOT tag and finaly
creates a new SNAPSHOT-pom on head. If you now do finish the gitflow
release, this SNAPSHOT-pom will go on the master branch. But gitflow
defines master as the stable production branch. There should no
SNAPSHOT-pom exist on the master branch.

Am I mistaken?

Regards,
Lars

Mark Derricutt

2011-07-26 10:52:26 UTC

Permalink

Before cutting the release, I start a new release branch, do the maven release, then when I'm happy, finish the release branch, THEN push to origin

$ git flow release start 3.4.5
$ mvn release:prepare release:perform
$ git flow release finish 3.4.5
$ git push && git push --tags

At least thats my work flow. There may be one or two fix up patches before I finish the release branch, if I need to roll back the release and tweak something ( I'll git tag -d the maven made tag if things for that far ).

After the git flow release is finnished, both master and develop sit at the next -SNAPSHOT version, this actually works out nice as it means you can then at some point do a "git flow hotfix start..." if need be to patch the last release ( which branches from master ).

Master will always be the code at the time the git flow release branch finished, it's not necessarily a direct match to your maven repo.

As for our feature branches, we also use Gerrit for code review, so tend to start a feature for a bug ticket, do some code, push it to gerrit for review and ONLY finish the git flow feature once its passed the review.

Hello Mark,

Post by Mark Derricutt
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.1</version>
<configuration>
<goals>deploy</goals>
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>
</configuration>
</plugin>
In this configuration maven does a local checkout, and doesn't require a git push during release.
This means after a maven release, I do my git-flow release, THEN push the master/develop branch to my origin.

I'm sorry, I don't understand. You first run the maven-release-plugin?
On which gitflow-branch (develop, feature, release)?
I think the maven release results in a NON-SNAPSHOT tag and finaly
creates a new SNAPSHOT-pom on head. If you now do finish the gitflow
release, this SNAPSHOT-pom will go on the master branch. But gitflow
defines master as the stable production branch. There should no
SNAPSHOT-pom exist on the master branch.
Am I mistaken?
Regards,
Lars
---------------------------------------------------------------------

Lars Fischer

2011-07-27 14:23:46 UTC

Permalink

Post by Mark Derricutt
Before cutting the release, I start a new release branch, do the maven release, then when I'm happy, finish the release branch, THEN push to origin
$ git flow release start 3.4.5
$ mvn release:prepare release:perform
$ git flow release finish 3.4.5
$ git push && git push --tags
At least thats my work flow. There may be one or two fix up patches before I finish the release branch, if I need to roll back the release and tweak something ( I'll git tag -d the maven made tag if things for that far ).
After the git flow release is finnished, both master and develop sit at the next -SNAPSHOT version,
this actually works out nice as it means you can then at some point do a "git flow hotfix start..."
if need be to patch the last release ( which branches from master ).

This breaks the gitflow master definition: "We consider origin/master
to be the main branch where the source code of HEAD always reflects a
production-ready state."

But without this restriction, your process should work.

Post by Mark Derricutt
Master will always be the code at the time the git flow release branch finished,
it's not necessarily a direct match to your maven repo.

It must not match the maven repo, but there should not be a SNAPSHOT-pom on HEAD

Also, if I configure the maven-release-plugin with

Post by Mark Derricutt
<pushChanges>false</pushChanges>
<localCheckout>true</localCheckout>

the maven release fails with:

[...]
[INFO] --- maven-release-plugin:2.2:perform (default-cli) @ master ---
[INFO] Checking out the project to perform the release ...
[INFO] Performing a LOCAL checkout from
scm:git:file://D:\dev\projects\maven.master\source\maven.master
[INFO] Executing: cmd.exe /X /C "git clone
file://D\dev\projects\maven.master\source\maven.master
D:\dev\projects\maven.master\source\maven.master\target\checkout"
[INFO] Working directory:
D:\dev\projects\maven.master\source\maven.master\target
[ERROR] The git-clone command failed.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 58.157s
[INFO] Finished at: Wed Jul 27 16:17:26 CEST 2011
[INFO] Final Memory: 5M/247M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2:perform
(default-cli) on project master: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-clone command failed.
[ERROR] Command output:
[ERROR] fatal: 'D\dev\projects\maven.master\source\maven.master' does
not appear to be a git repository
[ERROR] fatal: The remote end hung up unexpectedly
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

Do I have to make a special configuration on SCM?

Regards,
Lars

Mark Derricutt

2011-07-29 01:37:01 UTC

Permalink

Post by Lars Fischer

Post by Mark Derricutt
After the git flow release is finnished, both master and develop sit at the next -SNAPSHOT version,
this actually works out nice as it means you can then at some point do a "git flow hotfix start..."
if need be to patch the last release ( which branches from master ).

This breaks the gitflow master definition: "We consider origin/master
to be the main branch where the source code of HEAD always reflects a
production-ready state."
But without this restriction, your process should work.

Hrm - I still believe that master would be "production-ready-state" even with the -SNAPSHOT version, the code is in a state that ready for production release. If I did a maven release from there I'd get the same code built, with the only difference being the version number. If I checked out master and did a maven install, I'd expect to get a SNAPSHOT and not something that's going to overwrite existing released artifacts.

Post by Lars Fischer
It must not match the maven repo, but there should not be a SNAPSHOT-pom on HEAD

As above I beg to differ.

Post by Lars Fischer
[...]
[INFO] Checking out the project to perform the release ...
[INFO] Performing a LOCAL checkout from
scm:git:file://D:\dev\projects\maven.master\source\maven.master
[INFO] Executing: cmd.exe /X /C "git clone
file://D\dev\projects\maven.master\source\maven.master
D:\dev\projects\maven.master\source\maven.master\target\checkout"

Interesting - I see you have maven.master mentioned twice in the path - what do you have in your SCM settings element? And what is the root path of the git repo, and are you releasing from that directory?

Lars Fischer

2011-07-29 08:03:09 UTC

Permalink

Post by Mark Derricutt
Hrm - I still believe that master would be "production-ready-state" even with the -SNAPSHOT version,
the code is in a state that ready for production release. If I did a maven release from there I'd get
the same code built, with the only difference being the version number. If I checked out master and
did a maven install, I'd expect to get a SNAPSHOT and not something that's going to overwrite existing
released artifacts.

Post by Lars Fischer
It must not match the maven repo, but there should not be a SNAPSHOT-pom on HEAD

As above I beg to differ.

Hmm, this is what I understand from the gitflow documentation and what
results, when performing a manual release without the
maven-release-plugin.

But you are right, ignoring this restriction is no real problem.

Post by Mark Derricutt

Interesting - I see you have maven.master mentioned twice in the path -
what do you have in your SCM settings element?

<scm>
<connection>scm:git:ssh://***@myserver:22/maven.master.git</connection>
<developerConnection>scm:git:ssh://***@myserver:22/maven.master.git</developerConnection>
</scm>

Post by Mark Derricutt
And what is the root path of the git repo

The file path to the local clone is:
D:\dev\projects\maven.master\source\maven.master

There are two "maven.master", because I organize my projects in
subfolders with eclipse workspace folders parallel to the source
folders (e.g. D:\dev\projects\maven.master\workspace).

Post by Mark Derricutt
and are you releasing from that directory?

Both, the git and mvn commands are executed from
"D:\dev\projects\maven.master\source\maven.master"

Could this be a Windows problem?

I tried to perfom a second clone from the local file path with the
generated maven path:
"git clone file://D:\dev\projects\maven.master\source\maven.master"

This results in:

Cloning into devprojectsmaven.mastersourcemaven.master...
fatal: 'd:devprojectsmaven.mastersourcemaven.master' does not appear to be a git
repository
fatal: The remote end hung up unexpectedly

When using a different path with slashes
"git clone file:///d:/dev/projects/maven.master/source/maven.master/"
everything works fine.

Regards,
Lars

Lars Fischer

2011-07-29 08:12:50 UTC

Permalink

Post by Lars Fischer
Could this be a Windows problem?
I tried to perfom a second clone from the local file path with the
"git clone file://D:\dev\projects\maven.master\source\maven.master"
Cloning into devprojectsmaven.mastersourcemaven.master...
fatal: 'd:devprojectsmaven.mastersourcemaven.master' does not appear to be a git
repository
fatal: The remote end hung up unexpectedly
When using a different path with slashes
"git clone file:///d:/dev/projects/maven.master/source/maven.master/"
everything works fine.

Looks like I hit this issue: http://jira.codehaus.org/browse/MRELEASE-624

Regards,
Lars

Mark Struberg

2011-07-29 08:16:12 UTC

Permalink

hi!

Do you have <localCheckout> activated?
You might try disabling it, maybe there is a bug with that on windows.
<localCheckout> is meant to spare bandwith in huge projects by doing a git-clone file:// from the local git repo instead of cloning the upstream repo in release:perform.

LieGrue,
strub

Subject: Re: gitflow releases with maven?
Date: Friday, July 29, 2011, 8:03 AM

Post by Mark Derricutt
Hrm - I still believe that master would be

"production-ready-state" even with the -SNAPSHOT version,

Post by Mark Derricutt
the code is in a state that ready for production

release. If I did a maven release from there I'd get

Post by Mark Derricutt
the same code built, with the only difference being

the version number. If I checked out master and

Post by Mark Derricutt
did a maven install, I'd expect to get a SNAPSHOT and

not something that's going to overwrite existing

Post by Mark Derricutt
released artifacts.

Post by Lars Fischer
It must not match the maven repo, but there should

not be a SNAPSHOT-pom on HEAD

Post by Mark Derricutt
As above I beg to differ.

Hmm, this is what I understand from the gitflow
documentation and what
results, when performing a manual release without the
maven-release-plugin.
But you are right, ignoring this restriction is no real
problem.

Post by Mark Derricutt

Post by Lars Fischer
[...]
[INFO] --- maven-release-plugin:2.2:perform
[INFO] Checking out the project to perform the

release ...

Post by Mark Derricutt

Post by Lars Fischer
[INFO] Performing a LOCAL checkout from

scm:git:file://D:\dev\projects\maven.master\source\maven.master

Post by Mark Derricutt

Post by Lars Fischer
[INFO] Executing: cmd.exe /X /C "git clone

file://D\dev\projects\maven.master\source\maven.master
D:\dev\projects\maven.master\source\maven.master\target\checkout"

Post by Mark Derricutt
Interesting - I see you have maven.master mentioned

twice in the path -

Post by Mark Derricutt
what do you have in your SCM settings element?

Post by Mark Derricutt
And what is the root path of the git repo

D:\dev\projects\maven.master\source\maven.master
There are two "maven.master", because I organize my
projects in
subfolders with eclipse workspace folders parallel to the
source
folders (e.g. D:\dev\projects\maven.master\workspace).

Post by Mark Derricutt
and are you releasing from that directory?

Both, the git and mvn commands are executed from
"D:\dev\projects\maven.master\source\maven.master"
Could this be a Windows problem?
I tried to perfom a second clone from the local file path
with the
"git clone
file://D:\dev\projects\maven.master\source\maven.master"
Cloning into devprojectsmaven.mastersourcemaven.master...
fatal: 'd:devprojectsmaven.mastersourcemaven.master' does
not appear to be a git
repository
fatal: The remote end hung up unexpectedly
When using a different path with slashes
"git clone
file:///d:/dev/projects/maven.master/source/maven.master/"
everything works fine.
Regards,
Lars
---------------------------------------------------------------------

Lars Fischer

2011-07-29 08:34:19 UTC

Permalink

Hello Mark,

I see, that you assigned MRELEASE-624. Thank you for the quick reaction!

Post by Mark Struberg
Do you have <localCheckout> activated?
You might try disabling it, maybe there is a bug with that on windows.
<localCheckout> is meant to spare bandwith in huge projects by doing a git-clone file:// from the local git repo instead of cloning the upstream repo in release:perform.

Yes, localCheckout=true and pushChanges=false are used, because the
maven-release-plugin should perform only local changes.
Gitflow has to do additional branching / merging, which has to be
pushed outside the maven-release-plugin.

Regards,
Lars

Mark Struberg

2011-07-29 08:42:44 UTC

Permalink

Hi Lars!

Oki, I understand. Will try to look at it the next week.

LieGrue,
strub

Subject: Re: gitflow releases with maven?
Date: Friday, July 29, 2011, 8:34 AM
Hello Mark,
I see, that you assigned MRELEASE-624. Thank you for the
quick reaction!

Post by Mark Struberg
Do you have <localCheckout> activated?
You might try disabling it, maybe there is a bug with

that on windows.

Post by Mark Struberg
<localCheckout> is meant to spare bandwith in

huge projects by doing a git-clone file:// from the local
git repo instead of cloning the upstream repo in
release:perform.
Yes, localCheckout=true and pushChanges=false are used,
because the
maven-release-plugin should perform only local changes.
Gitflow has to do additional branching / merging, which has
to be
pushed outside the maven-release-plugin.
Regards,
Lars
---------------------------------------------------------------------

Lars Fischer

2011-07-29 08:56:12 UTC

Permalink

Post by Mark Struberg
Oki, I understand. Will try to look at it the next week.

Great.

Thank you,
Lars

Mark Derricutt

2011-07-30 23:45:23 UTC

Permalink

It also makes sense in ANY git project IMHO as "upstream" does not really mean "cananical, master repository" as it does with subversion.

It also prevents proliferating any temporary release branches you might be using during the release, forcing a user to do a 'git push' during release can be annoying, as you might not even HAVE an upstream repository.

Post by Mark Struberg
<localCheckout> is meant to spare bandwith in huge projects by doing a git-clone file:// from the local git repo instead of cloning the upstream repo in release:perform.