maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibordig...@apache.org>
Subject Re: Using Git tags to cut releases to Maven Central from TravisCI
Date Wed, 07 Aug 2019 09:34:44 GMT
Ben, you have to delete the remote Tag from Git if you want to repeat the
release of the same version.
It happened many times to me and my colleagues that we had to delete the
tag for whatever reason, e.g. wrong SCM credentials or connectivity
problems.
So it was usual that we deleted the tag, fixed the problem and then we
repeated the process.
This maybe helps. It is the pseudocode of what has been done by our hands:

def ret = sh 'mvn release:prepare -DpushChanges=false'
sh 'git push origin tag yourTag'


if (ret) {
    sh 'git tag -d yourTag'
    sh 'git push origin :refs/tags/yourTag'
    // exit 1
} else {
    sh 'git push origin master'
    sh 'mvn release:perform -Darguments="-DskipTests'
    // ok
}


On Fri, Aug 2, 2019 at 5:19 PM Ben Podgursky <bpodgursky@gmail.com> wrote:

> Thanks Hervé and Matthieu.  I'm afraid I am not following this point:
>
> > An issue with solutions like yours is reproducibility : `git checkout
> X.Y.Z && mvn install`will not build again artifact-X.Y.Z
>
> I guess I am not stating it explicitly, but once I release version X.Y.Z, I
> would never change the tag to point to a different commit, much like I
> would not change the Git commit history once it was pushed to master.  In
> Git, this would require deleting the tag and recreating it.  Even if I felt
> like doing this, it wouldn't do much good, because I cannot re-release the
> artifact to central.
>
> > you can't really predict how RELEASE value will really be related to PREV
>
> This is reasonable, although since it's my repository I do know what the
> next version will be.  I do feel this could be resolved by wrapping the
> commands I listed into a simple script that increments the version (similar
> to how the deploy plugin does it, but without the commit).
>
> I appreciate the feedback, thanks for taking the time to read this.
>
>
>
> On Thu, Aug 1, 2019 at 11:02 PM Hervé BOUTEMY <herve.boutemy@free.fr>
> wrote:
>
> > thank you Matthieu for sharing
> >
> > to me, one key interesting part is:
> > > An issue with solutions like yours is reproducibility : `git checkout
> > X.Y.Z
> > > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > > considered minor depending on the use cases & needs.
> >
> > and with jgitver, there is the equivalent reproducibility issue: if a
> > release
> > creates a source tarball to be able to download and rebuild independently
> > from
> > source control (= something that is mandatory at Apache level, and IMHO a
> > good
> > practice), both Ben solution and jgitver fail at rebuilding
> >
> > I personally find these version changing commits *a key useful feature*:
> > when I
> > checkout any point in a projet scm history, whatever the scm (no Git is
> > not
> > the only scm in the world), I precisely know what precise version I'm
> > building
> > (be it a SNAPSHOT, where by definition the version is fuzzy, or a release
> > where
> > the version is strictly defined at a precise state for the whole source
> > tree)
> >
> >
> > What Maven could do better to me is avoiding modifying every pom.xml file
> > in
> > multi-module project: yes, here, modifying only the root pom would be an
> > improvement.
> > I know there is a MNG Jira issue (even if I can't find it right now)
> >
> >
> > But definitely, trying to remove versions changes at source level seems
> to
> > me
> > not not a good objective because these commits are useful: the codebase
> is
> > really switching from PREV-SNAPSHOT to RELEASE to NEXT-SNAPSHOT
> > And even the fact that:
> > - you can't really predict how RELEASE value will really be related to
> PREV
> > - you'll have to make a guess at choosing NEXT
> > proves that these changes at source level are useful.
> > What we should do is making them easier
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 1 août 2019, 11:23:33 CEST Matthieu BROUILLARD a écrit :
> > > Hi Ben,
> > >
> > > several years ago I created jgitver <https://jgitver.github.io> to
> cover
> > > such a use case and even more.
> > >
> > > It uses git information (tags, branches, commits, metadatas, ...) to
> > > automatically compute a version based on configurable rules.
> > > So like you I can simply do: `git tag X.Y.Z && mvn deploy`
> > > jgitver <https://jgitver.github.io> brings more features &
> configuration
> > > capabilities without never modifying the pom files (like `mvn versions
> > > -dnewVersion` does).
> > >
> > > It is a solution among others but it is worthwhile trying it.
> > >
> > > An issue with solutions like yours is reproducibility : `git checkout
> > X.Y.Z
> > > && mvn install`will not build again artifact-X.Y.Z ; but this can be
> > > considered minor depending on the use cases & needs.
> > >
> > > FYI here are the projects I maintain related to the topic:
> > >
> > >    - jgitver library: https://github.com/jgitver/jgitver
> > >    - jgitver maven extension:
> > >    https://github.com/jgitver/jgitver-maven-plugin
> > >    - jgitver gradle plugin:
> > https://github.com/jgitver/gradle-jgitver-plugin
> > >
> > > Regards,
> > >
> > > Matthieu
> > >
> > > On Wed, Jul 31, 2019 at 5:51 PM Ben Podgursky <bpodgursky@gmail.com>
> > wrote:
> > > > I've been experimenting with setting up Maven Central publishing
> from a
> > > > TravisCI build (since it's free for my OSS GitHub project), and I
> > ended up
> > > > with a pattern that I think is pretty nice to work with (I've
> struggled
> > > > with the maven-deploy-plugin in the past).
> > > >
> > > > I've written it up here
> > > >
> > > >
> >
> https://bpodgursky.com/2019/07/31/using-travisci-to-deploy-to-maven-centra
> > > > l-via-git-tagging-aka-death-to-commit-clutter/ but
> > > > tl,dr, the key thing I haven't seen used widely is the use of tags to
> > > > define release versions, eg:
> > > >
> > > > ```
> > > > if [ ! -z "$TRAVIS_TAG" ]
> > > > then
> > > >
> > > >     mvn --settings "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> > > >
> > > > org.codehaus.mojo:versions-maven-plugin:2.1:set
> > -DnewVersion=$TRAVIS_TAG
> > > > 1>/dev/null 2>/dev/null
> > > > else
> > > >
> > > >     echo "No tags, using snapshot version from pom.xml"
> > > >
> > > > fi
> > > >
> > > > mvn deploy -P publish -DskipTests=true --settings
> > > > "${TRAVIS_BUILD_DIR}/.travis/mvn-settings.xml"
> > > > ```
> > > >
> > > > This lets me cut a central release by just pushing a tag:
> > > >
> > > > ```
> > > > $ git tag 1.23
> > > > $ git push origin 1.23
> > > > ```
> > > >
> > > > I've used Maven a fair amount but I wouldn't consider myself
> perfectly
> > in
> > > > tune with best practices, so I'm curious what others think of this
> > > > approach, or if there are other streamlined central deploy setups
> > > > (especially from CI/Travis) that I missed.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Ben
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message