spockframework
Automatic releasing from Travis to Maven Central
Automatic releasing from Travis to Maven Central mechanism - a proposal
Rationale
There have been many very interesting features implemented in the PRs for the previous 2 years. Unfortunately most of them have been kept in a freeze what is very frustrating for their authors (what in the end limit the number of contributions to Spock). Luckily the situation seems to be changing very recently - PRs have started to be merged. This PR is a complement to that process.
Automatic releasing from Travis makes it possible to have the feature available in released version just minutes after being merge into master. Currently the versions are marked as beta (1.1.0-beta.1, 1.1.0-beta.2, ...), but the artifacts are properly versioned, released to Maven Central and will stay there until the end of time (not like snapshots) - with an ability revert to the previous working version in case of problems . Therefore the group of early adopters become wider and wider. IMHO it is crucial to get Spock Framework development back on track.
Usage
To trigger the release process a commit to master branch with [#DO_RELEASE] command in the message is required. It can be an artificial commit, like:
git commit -m "Trigger release" -m "[#DO_RELEASE]" --allow-empty
Or the command can be added to a merge commit in GitHub UI.
Limitations and corner cases
The process has some limitation and (while usually working with my POC project) has been submitted here to get feedback and raise a discussion. The releasing mechanism has been adjusted to existing Spock build configuration and specific requirements (like variants for different Groovy versions).
Limitations
- Only Groovy 2.4 variant is released - this would be very tricky to work with Nexus from different Travis builds. Other variants are still released as snapshots.
- Spock is released with Java 7 (instead 6). While the target version is still 1.6 some Axion dependencies (namely JGit) support only Java 7+ at runtime.
Corner cases
Why should I scary you :). There are some, but all should be able to solve manually when accidentally happen. I will update this point later. Some of them might become obsolete before my PR would be merged ;).
Technicalities
- Axion plugin by Adam Dubiel is used to manage versioning which is now based on Git tags
- my Nexus Stating plugin is used to automatically promote artifacts to Maven Central from a Gradle build
- Gradle logic (and sometimes hacks) to glue everything together
Further work
Code could be somehow refactored. However for a time being I wanted to reduce an impact on existing mechanisms.
This change is 
IMHO releases should be tagged as well as being reproducible, which requires that the version information is updated in SCM be it build.gradle or gradle.properties. So instead of having a special commit message, could we have the tag as a trigger?
An alternative to this is https://jitpack.io/ which provides on demand builds from github, via mvn coordinates. We've used a jitpacked version of cglib when they had no Java 8 compatible release yet. And actually there is an open PR #543
I'm going to close this, the release is semi automated which is fine for a project like Spock IMHO.