Do unsnapshot commit and tag before release build?

[Vampire]

Currently, first the unsnapshotting is done, then the release build and after that the unsnapshotting commit and tag are done. That means that you never do a release build from the actual release tag and always have a dirty worktree when building. So when you generate some version information from the revision and cleanliness state of the repository, you will always get the revision of the last commit before the release tag and a dirty worktree. Also if you used something like git-describe you will get uglier output than necessary as the tag is not yet present. Would it maybe be feasibly to do the respective commit and tag before the actual building and properly support rollback in case of failure?

[Vampire]

Of course it should not push on commit like now, but most probably have a dedicated push task that you then also can easily disable if you don't want a push at all.

[Hillkorn]

For having the right revision as build information it makes sense to me and as long as nothing is pushed to remote it should be fine. The only thing is the revert logic that might be a bit more complex but shouldn't be a blocker. I think it's done in its current way to have a more generic solution that works for svn too and in svn you also push on commit as I remember.

[Vampire]

As SVN is not a DVCS and you do any operating directly on the server, this is "correct". One could either only apply this logic to DVCS, or make it configurable.

You could delete the tag as rollback, but as the commit is done too, this cannot easily be undone in rollback.

Maybe the behaviour should be on by default for DVCS and off by default for non DVCS and be configurable.

[cschabl]

That means that you never do a release build from the actual release tag and always have a dirty worktree when building. So when you generate some version information from the revision and cleanliness state of the repository, you will always get the revision of the last commit before the release tag and a dirty worktree.

This affects SVN, too. If you publish the built artifact to a artifact repository as a 'afterReleaseBuild'-task, it won't contain the SVN revision of the SVN tag if it has been added to the artifact in the build step.

[cschabl]

I think it's done in its current way to have a more generic solution that works for svn too and in svn you also push on commit as I remember.

The Maven-Release-Plugin steps for SVN are like this:

• ...
• Create SVN tag
• Check out the tagged revision to the build-temp dir
• Do another Maven build in the temp-dir workspace
• Publish the artifacts built in the temp-dir workspace
• ...

[rnc]

I've just hit this as well - the design pattern is not the same as the Maven plugin which means if the build records the SHA (e.g. in the jar manifest) it gets the wrong SHA.

[rnc]

For our use, in order to get the correct SHA, I solved it by altering the task ordering (project-ncl/gradle-manipulator/pull/205)