netzwerg / gradle-release-plugin

Gradle plugin providing very minimal release version numbering (Git-specific)

⚠️ NO LONGER MAINTAINED – USE AT YOUR OWN RISK! ⚠️

gradle-release-plugin

Gradle plugin providing very minimal release version numbering.

The plugin assumes a MAJOR.MINOR.PATCH[-SNAPSHOT] version pattern kept in a version.txt file.

It provides the following functionality:

• Initializes project.version from version.txt
• Offers tasks for different release strategies:
  • release - Creates a tagged non-SNAPSHOT release (using the current version as specified in the version.txt file)
  • releaseMajorVersion - Upgrades to next major version & creates a tagged non-SNAPSHOT release.
  • releaseMinorVersion - Upgrades to next minor version & creates a tagged non-SNAPSHOT release.
• Prepares version.txt for next SNAPSHOT iteration (i.e. bumps PATCH portion)

Usage

IMPORTANT: In multi-module builds, these steps should only be performed on the root project

1. Create a version.txt (with e.g. 0.1.0-SNAPSHOT) right next to your build script
2. Apply the plugin in your build script (see below)
3. Call gradle clean release

Applying the plugin

The plugin is hosted on Bintray and can be applied as follows:

New plugin mechanism (as of Gradle 2.1):

plugins {
  id 'ch.netzwerg.release' version 'x.y.z'
}

Older Gradle versions:

buildscript {
  repositories {
    jcenter()
  }
  dependencies {
    classpath 'ch.netzwerg:gradle-release-plugin:x.y.z'
  }
}
apply plugin: 'ch.netzwerg.release'

Details

During the application phase, the plugin initializes the project.version according to the contents of a version.txt file (e.g. 1.2.3-SNAPSHOT).

During the configuration phase, the plugin checks if any of the releaseXXX tasks is called explicitly. It then upgrades the project.version and version.txt contents according to the following strategies:

• Task release: Remove -SNAPSHOT from current version (e.g. 1.2.3)
• Task releaseMajorVersion: Upgrade to next major version (e.g. 2.0.0)
• Task releaseMinorVersion: Upgrade to next minor version (e.g. 1.3.0)

During the execution phase, the releaseXXX tasks tag the Git repository and prepare the version.txt contents for the next SNAPSHOT iteration. The tasks perform the following steps:

• Commit modified version.txt
• Tag Git repo (e.g. v1.2.3)
• Increment version number in version.txt to next SNAPSHOT (e.g. 1.2.4-SNAPSHOT)
• Again commit modified version.txt
• Optionally push changes to Git remote (works from any branch)

Note that all releaseXXX tasks run non-interactively and are thus well suited for continuous integration.

Configuration

This plugin follows a "no surprise" policy. Consequently, no configuration is needed in the majority of cases. The following snippet illustrates all configuration options, their default values, and possible alternatives:

release {
  dependsOn build // 'distZip' could e.g be used in combination with the 'application' plugin
  push = false // 'true' would e.g. be useful when triggering the release task on a CI server
  versionSuffix = '-SNAPSHOT' // '.DEV' or '' (empty) could be useful alternatives
  tagPrefix = 'v' // 'r' or '' (empty) could be useful alternatives
}

Note: In multi-projects scenarios, the root project usually does not have a build task. Consequently, the release task will fail with its current default settings. Please use release.dependsOn subprojects.build (after the subprojects block) to work around this issue.

Read-Only Properties

Use project.release.versionFile to e.g. include the version.txt file in your final release bundle. The Git release tag can be accessed via project.release.tagName.

Acknowledgements

• etiennestuder (underlying plugindev)
• RichardGottschalk (PR #16)

License

This plugin is available under the Apache License, Version 2.0.

© by Rahel Lüthy

gradle-release-plugin's Issues

Publish on Bintray

Refactor to use extension rather expose task internals

Add support for flavor based version.txt

My Android project have multiple flavor. e.g , brand_1 , brand_2 and brand_3 i would like to maintain the separate version.txt file each flavor. Looks there is no support on the current version. Could you please add the support ?

Add `releasePatchVersion` task (identical to current `release` task)

Currently, the following tasks exist:

• release
• releaseMinorVersion
• releaseMajorVersion

The release task creates a patch release.

For consistency reasons, a releasePatchVersion task should be introduced. For backwards compatibility, release should be kept as an alias.

Include License

• LICENSE file in root
• License header in source

git executable output needs to be logged before exiting

commitVersionFile("Release v$project.version", releaseExtension)

this leads to the problem that when git command is called it cant interprete correctly:

git commit -m Release v0.0.1 version.txt

vs

git commit -m "Release v0.0.1" version.txt

Do not modify version.txt if gradle.startParameter.dryRun

Set up continuous integration for GitHub project

Support usage of abbreviated task names

Gradle supports usage of abbreviated task names, e.g. relMinVer instead of releaseMinorVersion. The plugin's strategy resolution fails when an abbreviated task name is being used.

gradle-release-plugin/src/main/groovy/ch/netzwerg/gradle/release/ReleasePlugin.groovy

Line 68 in e89c9dc

private static VersionUpgradeStrategy resolveVersionUpgradeStrategy(List<String> taskNames, String versionSuffix) {

Support configuration of versionFile name/location

Thereby replacing project.ext.versionFile

Could not determine the dependencies of task ':release'

Hi
I've added your plugin to my build.gradle file:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "com.github.jengelman.gradle.plugins:shadow:1.2.3"
        classpath 'ch.netzwerg:gradle-release-plugin:1.1.0'
    }
}

plugins {
    //Gradle release plugin from: https://github.com/netzwerg/gradle-release-plugin
    id 'ch.netzwerg.release' version '1.1.0'
}

subprojects {
    group 'myGroup'

    version '1.0.0.0-SNAPSHOT'

    apply plugin: 'java'

    apply plugin: 'com.github.johnrengelman.shadow'
    apply plugin: 'maven'

    // Use Java 8
    sourceCompatibility = 1.8

    repositories {
        mavenLocal()
        jcenter()
        maven {
             // Repositories we use
        }
    }

    dependencies {

        // Dependencies we use
    }

}

When I run:

gradle tasks

I get the following error:

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':tasks'.

  Could not determine the dependencies of task ':release'.

Why do we need a version.txt file

First of thanks for the plugin. I like the plugins outstanding simplicity.

I have a question regarding the version.txt file. Why is it needed? Would it not be better to just update the gradle build file instead?

Provide different release tasks for upgrading different parts of the version

Allow to bump up major, minor, or patch version through different Gradle tasks.

Hook to publish release

Is there any way to build and publish release artifacts:

• build snapshot
• update version
• commit version
• push version
• tag version
• build release
• publish release
• update version
• commit version
• push version

Task 'release' should depend on 'build' by default

In other words: Offer 'vanilla' behavior which doesn't need configuration at all

Master branch is moved after pushing with the plugin

Hello Rahel,

I enabled to push on release and I now have the problem that the plugin is pushing to a new master branch. On the screenshot you see TAG 1.0.1. This was actually my master brach 19da802 it now became 1.0.1

On the second screenshot you can see that the current master is a complete new branch.

Jenkins is checking out the code in this way

Checking out Revision 19da802c997053214cef316e895e018089286c11 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 19da802c997053214cef316e895e018089286c11 # timeout=10
 > git branch -a -v --no-abbrev # timeout=10
 > git checkout -b master 19da802c997053214cef316e895e018089286c11
 > git rev-list 19da802c997053214cef316e895e018089286c11 # timeout=10

Is this normal behavior

pass in authentication credential and patch release

This seems to be a fairly simple but very useful plugin. I got a questions:

1. how to configure authentication username/password for git
2. Is there releasePatch task?

Thanks
-cl

Setting `project.version` in `project.afterEvaluate` is too late

If plugins are applied in "wrong" order, some artifacts which base their names on project.version are named incorrectly because the property is not initialized yet

Requires partial revert of #12

Selectively push release tag (instead of all tags)

Clarify docs about the version pattern

The docs say, MAJOR.MINOR.PATCH[-SNAPSHOT] is the expected pattern. But, what I just found out is that MAJOR.MINOR[-SNAPSHOT] works as well (which is great). The docs could be more clear about that.

Wrong message upon version parsing exception

push=true is not pushing

I am calling gradle -x test -s -d release -Prelease.push=true from my Jenkins/CI server to create tag and push the changes into git.

From the debug output I see that a tag was committed successfully but it is never pushed to origin/remote.

14:37:51.655 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING
14:37:51.657 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: command 'git'.
14:37:51.661 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED
14:37:51.662 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...
14:37:51.663 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'git''
14:37:51.695 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: SUCCEEDED
14:37:51.696 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'command 'git'' finished with exit value 0 (state: SUCCEEDED)
14:37:51.697 [DEBUG] [ch.netzwerg.gradle.release.ReleaseTask] [detached HEAD 593f269] Prepare next release v0.0.6-SNAPSHOT

when adding the push entry in my build.gradle it is working.

release{
   push=true
}

is the parameter -Prelease.push=true incorrect?

All tasks only increment patch version (in submodules)

Regardless of whether I run "release", "releaseMinorVersion", or "releaseMajorVersion" the version always increments the last number. So "1.0.0-SNAPSHOT" will increment to "1.0.1-SNAPSHOT"

I think this is the offending line, but I'm not familiar enough with gradle plugins to be sure:
https://github.com/netzwerg/gradle-release-plugin/blob/master/src/main/groovy/ch/netzwerg/gradle/release/ReleaseTask.groovy#L58

Multi-project setup: `release.dependsOn` configuration should not be mandatory

A release block without setting the 'dependsOn' property fails the build

Provide configuration option to use suffix other than '-SNAPSHOT'

Provide option to also create a release on GitHub

I'm pretty sure you can do a release on GitHub through their REST API.
To be consistent, the same versions, titles, etc. should be used (where there is an overlap).

Push to current branch rather than master

git push origin HEAD

A handy way to push the current branch to the same name on the remote.
git push documentation

Stop relying on `project.afterEvaluate` for project version initialization

Using project.afterEvaluate to trigger project version initialization causes trouble in multi-project builds (subproject-versions not properly initialized).

Version.txt in subprojects

Is it necessary to have a separate version.txt in all subprojects? or am I doing something wrong? I have a version.txt in the main project root also.

A problem occurred evaluating root project 'zipkin'.
> Failed to apply plugin [id 'ch.netzwerg.release']
   > /Users/main_project/subproject/version.txt (No such file or directory)

Issue with Single Quotes on Windows

Hi,

The plugin has worked well on MacOS, running the gradle script on a Windows machine using GitBash, the following error results. Is this an issue with the use of Single Quotes rather than Double Quotes? If so, what recommendations do you have for resolving this?

Thanks!

:releaseerror: pathspec 'version.txt' did not match any file(s) known to git.
FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':release'.

Process 'command 'git'' finished with non-zero exit value 1

Expose VCS tagName as property

Provide configuration to push changes to Git remote

Build succeeds even if git push fails

If the git push command fails (for example, because someone else pushed a commit up while the release was running), then the release task should fail, but it does not. Instead, the build continues.

Unable the push tags

Hello everyone.

I'm wondering why I cannot push from some machines (in this case centos).

I got always the next issue after run gradle release

> Task :shadowJar
> Task :release
To [email protected]:group*/some-repo-path.git
 * [new tag]         v1.0.14 -> v1.0.14
error: unable to push to unqualified destination: HEAD
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to '[email protected]:group*/some-repo-path.git'

Do you have any idea about this?

Thanks in advance

Should it be mentioned it works only with git?

or am I mistaking?