Giter VIP home page Giter VIP logo

gradle-release-plugin's Introduction

Gradle release plugin (Git and Subversion) Build Status

This is a Gradle plugin that makes it very simple to automate release management when using git or Subversion as vcs. The plugin is responsible for knowing the version to build at all times. You should not use this plugin if you want/need to be in control of the version name/number.

In the case of a normal gradle build, the plugin generates a version name based on the current branch name: ${branchName}-SNAPSHOT.

If you run the task releasePrepare, the plugin will query git/svn for the latest release tag and add one to the number. The artifacts will have a version name like master-REL-1 (if this is the first time you run :releasePrepare). A release tag with the version name will be created in git/svn. (The tag will NOT be pushed in this task when using git.)

If you want the artifacts to be uploaded and the releaseTag to be pushed, run the releasePerform task. This task depends on releasePrepare so it will run first.

Notice: The build will fail if you try to run releasePrepare again, with an error message telling you that there is no changes since the last release tag. If you want to rebuild a release, just run a normal gradle build and the plugin will figure out that the current HEAD is a release tag and use the release version. The same applies if you checkout a release tag and run build.

Usage

Add the following to your build file to setup where the plugin should be downloaded from:

apply plugin: 'gitrelease' // or apply plugin: 'svnrelease'

buildscript {
  repositories {
    mavenCentral()
  }

  dependencies {
    classpath 'no.entitas.gradle:gradle-release-plugin:1.16'
  }
}

Notice: This must be in the root build file in a multi-module build, that is, the release plugin can only be applied at the top level.

To setup where your artifacts should be deployed, use a regular uploadArchives section. This is an example of deploying to a Maven repository:

uploadArchives.repositories.mavenDeployer {
  uniqueVersion = false

  repository(url: '...release distribution url...') {
    // username/password resolved from gradle.properties
    authentication(userName: project.username, password: project.password)
  }

  snapshotRepository(url: '...snapshot distribution url...') {
    // username/password resolved from gradle.properties
    authentication(userName: project.username, password: project.password)
  }
}

In a multi-module build this will typically be setup for each subproject that needs to be deployed.

Configuration

The closure below shows the available configuration options and their default values:

release {
    failOnSnapshotDependencies = false
    versionStrategy = { currentVersion ->
        if (System.properties['release.version']) {
            System.properties['release.version']
        } else {
            new BigDecimal(currentVersion).add(BigDecimal.ONE).toPlainString()
        }
    }
    startVersion = { currentBranch -> "1" }
}

failOnSnapshotDependencies when set to true the build will fail if it has any snapshot dependencies.

versionStrategy a closure for calculating the next version number, given the current (as a String). The default implementation is to add 1, or if the system property release.version is set, use its value.

startVersion which version to start counting from.

Tasks

releasePrepare

  • Checks that there are no local modifications (git/svn status)
  • Checks that your current HEAD is not a release tag
  • The projects are built with version resolved from the latest git release tag + 1
  • Creates a git tag for your current head named ${branchName}-REL-${version}

releasePerform

  • This task depends on the :releasePrepare task
  • Depends on uploadArtifacts and pushes tags if using git

Known issues and limitations

  • Only tested on Java projects
  • The releasePerform task has only been tested with Nexus and http upload

gradle-release-plugin's People

Contributors

ari avatar mkotsbak avatar mkrabset avatar stianh avatar stigkj avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

gradle-release-plugin's Issues

Instructions confusing for svn

Split instructions for git and svn

*** git

releasePrepare

  • Checks that there are no local modifications (git status)
  • Checks that your current HEAD is not a release tag
  • Checks there are no commits not yet pushed
  • Version is set to latest git release tag + 1
  • The project is cleaned and built
  • Creates a git tag for your current head named ${branchName}-REL-${version}

releasePerform

  • This task depends on the :releasePrepare task
  • Runs task uploadArtifacts
  • Pushes tag created by releasePrepare

*** svn

releasePrepare

  • Checks that there are no local modifications (svn status)
  • Checks that there are no commits not yet pulled from the repository
  • Version is set to latest svn release tag + 1
  • The project is cleaned and built

releasePerform

  • This task depends on the :releasePrepare task
  • Runs task uploadArtifacts
  • Commits a tag for the release

Can you confirm the above is correct?

The logic for deciding start & next version number should be externalized

Add an option to the plugin that holds a closure which will be called when needing the next version number.

This means expanding the plugin's extension object with this option that by default holds a closure that has the same logic as what is done today:

nextVersionNumber = currentVersionNumber + 1

Fails on a project with a file dependency

A file dependency like the following

providedCompile files (System.getProperty("java.home")+"/../lib/tools.jar")

does not have a version, so cannot be checked for being a SNAPSHOT
or not. Must change to not check for file dependencies

Option to set the initial version "number" on current branch

Not having migrated our workflow properly to the "git way", we are "moving" a version of the codebase between different branches. Example: master --> RELEASE --> PRODFIX

With this setup, it is hard to track a version with this plugin creating versions "numbers" based on the branch name and an increasing number.

Not sure what would be the correct way to do this; maybe have a property that can be set on the command line for an initial version "number" on the branch?

Merging releasePrepare and releasePerform

I am trying to reconcile the gap between these two tasks. At the moment there are inconsistencies.

  1. releasePrepare creates a tag in git but not in svn
  2. releasePerform can be run without the prepare step and the results are not predictable
  3. releasePerform appears in "gradle tasks" but releasePrepare doesn't.

I can see that the separation is similar to maven's two step process. But in maven 'state' is recorded in config files written to disk after releasePrepare. That way releasePerform knows what to do.

I propose that the separation between the two things is not needed. Instead we could have one task "release" which:

  1. Performs integrity checks (uncommitted changes, are we on HEAD). Exception -> STOP
  2. Are we on a tag? YES -> goto step 3B
    3A. Set version from user input or from highest tag +1
    4A. Build and test. Failure -> STOP
    5A. Create tag and push
    6A. uploadArtifacts (possibly this task should be not part of this plugin and left to the user to run separately?)

3B. We are already on a tag so set the version from the name of the tag
4A. Build and test
5A. uploadArtifacts

In effect, if we are already on a tag, all this plugin really does is set the version.

How does all the above sound as a workflow? Does this fit into your concept? Why do we want to keep the separation of the two tasks?

Flexibility for SCM tag name and tag matcher

It would be nice to provide custom matchers to extract the tag versions.

Let's assume that someone has tag names conventions such as PRJ_VersionNumber_RELEASE.

It looks like there's no way to customize the next tag name as well as the latest tag (Name and version as there is no match found with the hardcoded regex matcher).

If possible such a feature could be provided via a closure in the same way as the versionStrategy extension point.

svn version strategy

Git has the ability to have a version strategy. Why does svn not have the same?

In particular, I want to be able to pass a version to the script at build time:

# gradle releasePrepare -Drelease-version=3.0

Just incrementing numbers forever isn't enough for us. We need to be able to pick release version numbers, and create all sorts of non-numeric versions like 3.0b3

Remove dynamic properties

Dynamic properties are deprecated: http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html
Deprecated dynamic property: "defaultProject" on "root project 'buildSrc'", value: "build_5mgvj31rurcj5uts...".
Deprecated dynamic property: "fixedProject" on "root project 'buildSrc'", value: "build_5mgvj31rurcj5uts...".
Deprecated dynamic property: "sonatypeUsername" on "root project 'buildSrc'", value: "".
Deprecated dynamic property: "sonatypePassword" on "root project 'buildSrc'", value: "".
Deprecated dynamic property: "installer" on "root project 'buildSrc'", value: "org.gradle.api.publica...".
Deprecated dynamic property: "deployer" on "root project 'buildSrc'", value: "org.gradle.api.publica...".

Proper syntax is something like

project.ext.set...

But as I don't understand what these properties are even doing, I'm not game to fix them.

Exception in the Git Release Plugin when there's no remote origin

For newly initialized Git Repositories or just local repositories, sometimes there's no remote origin.

This causes errors when performing a release as show below.

Caused by: java.lang.NullPointerException: Cannot get property 'aheadCount' on null object
    at no.entitas.gradle.git.GitVersion.branchIsAheadOfRemote(GitVersion.groovy:91)
    at no.entitas.gradle.git.GitVersion.releasePreConditions(GitVersion.groovy:83)
    at no.entitas.gradle.git.GitVersion.setup(GitVersion.groovy:56)
    at no.entitas.gradle.git.GitVersion$_closure1.doCall(GitVersion.groovy:48)

Fails on Gradle v1.3

It seems Gradle v1.3 has changed how it fetches the version for a module, as it does not call the version method in the release plugin. The result is a NPE when using the corresponding ModuleVersionIdentifier internally in Gradle.

Version number passed in command-line has no effect

Passing the -Drelease.version in command line has no effect on the tag taken . Tag is always coming out as -REL-n ; example - trunk-REL-1, trunk-REL-2.

This is happening when using SVN. Haven't tried for Git

Feedback - can't be used for Android projects

The Android plugin is not compatible with the java plugin, and the java plugin is used by this plugin. If you try to use it, you will get BUILD FAILED with message:

"The 'java' plugin has been applied, but it is not compatible with the Android plugins."

Override svn tag path

Hi,

Is there any configuration/properties which i can change the path of the tags when i do a release on svn?

Thank you in advance

Wrong branch is chosen when 2 branches are pointing to the same commit

When trying to release from a checked out branch which is pointing to the same commit as another branch, there is a possibility that the name of the other branch is used.

This is because git-name-rev is used for finding current branch, but it does not handle this case correctly all the time. Use git-symbolic-ref instead.

Must handle branch names containing path characters correctly

If the branch name is

release/some-name

the created artifact will be named 'module name'-release/some-name.'extension', that is, 'module name' will not be part of the filename. For a multi-module project this means every artifact will be called the same.

To handle this properly, all path characters must be replaced with another character; '_' is a good choice.

An example for where this is used is in git flow where '/' is used in branch names for prefixing with for example 'release/', 'feature/'' and 'hotfix/'.

Add support for Linux version numbering

That is:

If on master, "git describe" gives "v3.1.0-nn-xxxx", make version "v3.2.0". (maybe add an option to make version "v4.0.0" instead)
If on branch "1.1" and "git describe" gives "v1.1.7-nn-xxxx", make version "v1.1.8"

Install seems not to work properly

After running "gradle install" on this code and adding "apply plugin: 'gitrelease'" to the project, I get error:

Cause: Plugin with id 'gitrelease' not found.

Version believes unspecified on gradle 1.6

Hi,

i'm using gradle 1.6. I'm on a branch with name 8.5.0. The release tasks creates the correct tags in the git, 8.5.0-REL-1 and so on, but the deployed maven artifacts doesn't have a corrent version. The versioning of the jar and pom is "unspecified". If I add the version attribute to the subproject, then these version is used for the deployment, and not the branch-REL-X one.

Do I miss something?

Regards

Signing install task

I'm looking to create submit some additions, but first I'd like to understand gradle-release-plugin's build. Out of curiosity, why are you' going to all the trouble of signing during the install task? (uploadArchives seems obvious.)

Were you experiencing that the package type was not "jar"? With the Java plugin applied (via the groovy plugin), the packaging will always be 'jar'

Have you considered including gradlew via a Wrapper task to ensure a certain version of gradle is used to build the plugin?

Deriving release version from tags + 1

One part of this plugin which doesn't work for us is the way in which it always derives the next version from the existing tags. We can override the closure and give it some functionality of our own, but I want this to work completely differently. That is, more like the maven release process with the version provided as a parameter by the user.

gradle releasePrepare -DreleaseVersion=4.0

If I engineered this kind of change (still keeping your option to derive from tags), would you accept such patches or would I be better keeping my own fork of this plugin?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.