Push tagged builds automatically

[jgeewax]

It'd be really nice to make our doc builds and the maven push all automagical based on the tags we have in the git repository.

/cc @stephenplusplus : Maybe you can add more color on how we did this for node.

(This stems from the discussion on #51)

[stephenplusplus]

Unfortunately, I'm not too familiar with the workflow and practices of a Java developer. We're lucky with Node, because Travis gives us the behavior we're looking for out of the box with an npm deploy provider: (see our travis.yml). If we push a new tag to the repo, it automatically runs our release.sh script to build the docs before publishing to npm on its own.

Travis says the solution for projects that don't have a supported deploy provider is just using the after_success block. Only one configuration is possible (as far as I know), and it has already been written to push snapshot updates. To get it to do something on tagged releases should be possible as well, but it can only be one or the other.

However, since you can point after_success to a shell script, you can get away with doing more complicated things. This may not be a great idea, but in theory, the following should be possible:

1. Run your after_success script (say, on-push.sh on every push to master)
2. on-push would somehow check for the most recent released version
3. on-push would somehow check for the latest tag in your repo
4. on-push would use 3 & 4 to determine if you need to push a snapshot or push a release & build the docs

Sorry I couldn't be more help.

[mziccard]

Let me add here what I wrote in a not-so-related pull request. When a tag is pushed to the repository the $TRAVIS_TAG is set to its value. In the after_success script this variable can be inspected to check whether we have to push a snapshot (e.g. tag v0.8.0-SNAPSHOT) or a release (e.g. tag v0.8.0).

Before depolying in maven we also need to update version numbers in all pom.xml files (and READMEs). I see two solutions here:

1. Doing it by hand (possibly using a script) before pushing the tag
2. Doing it in Travis after pushing the tag: that is, let Travis get the version from $TRAVIS_TAG, update all pom.xml and READMEs and pushe a commit with the updated files

The problem I see with approach 2 is that we will have a commit tagged with a newer version while maven's pom.xml and READMEs are still to the previous version as Travis commit arrives later (is triggered by the tag). Forcing the tag to move to the next commit is a no-no.

I like approach 2 because it rely solely on git tags to publish a new version but I do not like having version update commits after their corresponding tag. Sticking to a 1-like solution might be better with this respect. Any thoughts?

[aozarov]

I also like approach 2 but let me make sure I understand it...
Can Travis be triggered just by pushing a tag (without code change)?
If so, can Travis do something like the following?

if release_tag:
release_version = version from release_tag
prev_version = version from pom.xml
set poms version to release version and trigger site & maven push (don't commit poms)
if prev_version <= release_version:
modify poms to release_version + 1 + "-SNAPSHOT" and commit

[mziccard]

Yes Travis should be triggered even if you push only tags and what you write should be doable without too much pain. The problems I see here are:

• In git you will have a commit tagged with a version while in the commit pom and READMEs are set to an older (snapshot) version
• Consider the case you tag with release version 1.6.0, what's the next SNAPSHOT version? 1.6.1-SNAPSHOT or 1.7.0-SNAPSHOT? In either case, what if you then jump to release version (and tag) 2.0.0? You end up being in release 2.0.0 having no snapshots for it but you will have either 1.7.0-SNAPSHOT or 1.6.1-SNAPSHOT with no corresponding release version.

[aozarov]

Yes, in case of release version 1.6.0 I would expect it to automatically move the SNAPSHOT version in the POM to 1.6.1-SNAPSHOT.

As long as the tag release is smaller than POM version, we don't change the POM in gitHub (just locally for the maven and site pushes).

I don't see the difference between the 1.6.0 case and the 2.0.0 case (so maybe I don't understand the question). It should be fine to have such a jump (POM would be set to 2.0.1-SNAPSHOT) and site/maven will be pushed with a 2.0.0 release.
Maven dependencies should be fine with not having 1.7.0-SNAPSHOT or a like and should pick the latest release (snapshot or not) that is <= 1.7.0-SNAPSHOT.

Another option to consider is pushing tags just with a release type indicator.
e.g. major_relase, minor_release, incremental_release and according to that we will modify
the pom to push artifcats to maven and generate a site as well as modifying the pom in gitHub.
Thoughts?

[ajkannan]

I vote for the first option (using a script to update the poms before pushing the tag) because of the first bullet point (the tagged version will have an outdated pom.xml). I think option 2 would be a bit confusing down the line, especially if anybody checks out the repository using that tag.

[jgeewax]

/cc @mziccard @dhermes @stephenplusplus -- just for thoughts....

[jgeewax]

Just out of curiosity... shouldn't this be a solved problem? Is there something going on that we overlooked? I feel like any real Java project should have already figured this out..........

[mziccard]

@aozarov The problem with jumping to 2.0.0 is not after the jump but before it:
Imagine you release version 1.6.0. Then the POM is moved automatically to 1.6.1-SNAPSHOT and every push then triggers a maven deploy of 1.6.1-SNAPSHOT. If you then decide to jump to release 2.0.0 by pushing the corresponding tag you will end up having published 1.6.1-SNAPSHOT but no 1.6.1 release as well as 2.0.0 release but no 2.0.0-SNAPSHOT. This is not a big deal.

@jgeewax I browsed some real java projects and it's a huge mess, some do version changes by hand like in approach 1 (e.g. hibernate but they use gradle), others (e.g. Spring) have a build bot triggered from outside git (I think) that fetches the repo, moves to new version the POMs and pushes the changes as well as a version tag back to the repository, publishes the artifact and finally puts a new "development version" in the POMs and pushes to git.

[aozarov]

@mziccard Yes, I understand but I also don't think it is a big deal (it should be totally fine to skip a release for a snapshot when a change is no longer minor or to have a release without prior snapshots).

What did you think about using major/minor/incremental tags instead of specifying the version (and automate the book-keeping)? We could always also support jump/reset to specific version if need to...

@ajkannan can you describe the confusion?

@jgeewax I also looked at guava and Guice and though they both seem to use gitHub releases/tags I didn't find any evidence of automation for it. They do automate javadoc & maven snapshots push in a similar way to what we already do (but they do not use maven site).

[jgeewax]

Maybe we can look at a non-Google project for guidance?

[mziccard]

@aozarov You mean using just major/minor/incremental as tag name without any version information? While I understand your point, in git a tag must be unique so you can not use them as if they were actions. A tag is like a label you add to a commit to allow users to clone the repository for a specific version/bug fix/feature/etc.

[ajkannan]

@aozarov To clarify what I said earlier regarding the confusion with Option 2:
If developers were to type git checkout -b version007 v0.0.7, their pom.xml files would still say 0.0.7-SNAPSHOT, not 0.0.7.

[aozarov]

@ajkannan I see your point.

@mziccard can we make Travis delete the tag (so we can re-use it next time) and then instead let Travis apply the specific version tag (after changing POMs version associated with the tag for both site/maven and github code check-in [to answer @ajkannan concern]). After that Travis can change POMs to the next snapshot version. Is that too much to task from Travis or gitHub? If so, than I think I would also favor a manually triggered script for releases while automating the snapshots [as we already do].

@jgeewax Hibernate and Spring that were pointed out by @mziccard are not Google projects.
Considering this list for top libraries on GH I also looked at Junit & log4J and didn't find evidence for automatically using GH releases.

[mziccard]

@aozarov Uh I see. I would say that this is an unorthodox way of using tags :) Deleting a remote tag is not very common unless you pushed it by accident but it can be done and I am not against this approach! Somebody else's thoughts would be valuable at this point.

[jgeewax]

I'd agree... I think deleting remote tags is ... a bit scary.

[garrettjonesgoogle]

The repo currently has an automated release process based on the version in the pom. Closing out this issue.