Git Product home page Git Product logo

gradle-release's Introduction

gradle-release plugin

Build Status Gradle Plugin page

Introduction

The gradle-release plugin is designed to work similar to the Maven release plugin. The gradle release task defines the following as the default release process:

  • The plugin checks for any un-committed files (Added, modified, removed, or un-versioned).
  • Checks for any incoming or outgoing changes.
  • Checkout to the release branch and merge from the working branch (optional, for GIT only, with pushReleaseVersionBranch)
  • Removes the SNAPSHOT flag on your project's version (If used)
  • Prompts you for the release version.
  • Checks if your project is using any SNAPSHOT dependencies
  • Will build your project.
  • Commits the project if SNAPSHOT was being used.
  • Creates a release tag with the current version.
  • Checkout to the working branch (optional, for GIT only, with pushReleaseVersionBranch)
  • Prompts you for the next version.
  • Commits the project with the new version.

Current SCM support: Bazaar, Git (1.7.2 or newer), Mercurial, and Subversion

Installation

The gradle-release plugin will work with Gradle 6.0 and beyond

Legacy plugin application

buildscript {
  repositories {
    maven {
      url 'https://plugins.gradle.org/m2/'
    }
  }
  dependencies {
    classpath 'net.researchgate:gradle-release:3.0.2'
  }
}

apply plugin: 'net.researchgate.release'

Plugin DSL

plugins {
  id 'net.researchgate.release' version '3.0.2'
}

Please refer to the Gradle DSL PluginDependenciesSpec to understand the behavior and limitations when using the new syntax to declare plugin dependencies.

Usage

After you have your build.gradle file configured, simply run: gradle release and follow the on-screen instructions.

Configuration

As described above, the plugin will check for un-committed files and SNAPSHOT dependencies. By default the plugin will fail when any un-committed, or SNAPSHOT dependencies are found.

Below are some properties of the Release Plugin Convention that can be used to make your release process more lenient

Name Default value Description
failOnCommitNeeded true Fail the release process when there are un-committed changes. Will commit files automatically if set to false.
failOnPublishNeeded true Fail when there are local commits that haven't been published upstream (DVCS support)
failOnSnapshotDependencies true Fail when the project has dependencies on SNAPSHOT versions unless those SNAPSHOT dependencies have been defined as 'ignoredSnapshotDependencies' using the syntax '$group:$name'
failOnUnversionedFiles true Fail when files are found that are not under version control
failOnUpdateNeeded true Fail when the source needs to be updated, or there are changes available upstream that haven't been pulled
revertOnFail true When a failure occurs should the plugin revert it's changes to gradle.properties?
pushReleaseVersionBranch null (GIT only) If set to the name of a branch, the `release` task will commit the release on this branch, and the next version on the working branch.

Below are some properties of the Release Plugin Convention that can be used to customize the build

Name Default value Description
tagTemplate $version The string template which is used to generate the tag name. Possible variables are $version and $name. Example: '$name-$version' will result in "myproject-1.1.0". (Always ensure to use single-quotes, otherwise `$` is interpreted already in your build script)
preCommitText This will be prepended to all commits done by the plugin. A good place for code review, or ticket numbers
preTagCommitMessage [Gradle Release Plugin] - pre tag commit: The commit message used to commit the non-SNAPSHOT version if SNAPSHOT was used
tagCommitMessage [Gradle Release Plugin] - creating tag: The commit message used when creating the tag. Not used with BZR projects
newVersionCommitMessage [Gradle Release Plugin] - new version commit: The commit message used when committing the next version
snapshotSuffix -SNAPSHOT The version suffix used by the project's version (If used)

Below are some properties of the Release Plugin Convention that are specific to version control.

VCS Name Default value Description
Git requireBranch main Defines the branch which releases must be done off of. Eg. set to `release` to require releases are done on the `release` branch (or use a regular expression to allow releases from multiple branches, e.g. `/release|main/`). Set to empty string "" to ignore.
Git commitOptions {empty} Defines an array of options to add to the git adapter during a commit. Example `commitOptions = ["-s"]`
Git pushOptions {empty} Defines an array of options to add to the git adapter during a push. This could be useful to have the vc hooks skipped during a release. Example `pushOptions = ["--no-verify"]`
Git signTag false Adds `-s` parameter to the tag command

To set any of these properties to false, add a "release" configuration to your project's build.gradle file. Eg. To ignore un-versioned files, you would add the following to your build.gradle file:

release {
  failOnUnversionedFiles = false
}

Eg. To ignore upstream changes, change 'failOnUpdateNeeded' to false:

release {
  failOnUpdateNeeded = false
}

This are all possible configuration options and its default values:

release {
    failOnCommitNeeded = true
    failOnPublishNeeded = true
    failOnSnapshotDependencies = true
    failOnUnversionedFiles = true
    failOnUpdateNeeded = true
    revertOnFail = true
    preCommitText = ''
    preTagCommitMessage = '[Gradle Release Plugin] - pre tag commit: '
    tagCommitMessage = '[Gradle Release Plugin] - creating tag: '
    newVersionCommitMessage = '[Gradle Release Plugin] - new version commit: '
    tagTemplate = '${version}'
    versionPropertyFile = 'gradle.properties'
    versionProperties = []
    snapshotSuffix = '-SNAPSHOT'
    buildTasks = []
    ignoredSnapshotDependencies = []
    versionPatterns = [
        /(\d+)([^\d]*$)/: { Matcher m, Project p -> m.replaceAll("${(m[0][1] as int) + 1}${m[0][2]}") }
    ]
    pushReleaseVersionBranch = null
    scmAdapters = [
        net.researchgate.release.GitAdapter,
        net.researchgate.release.SvnAdapter,
        net.researchgate.release.HgAdapter,
        net.researchgate.release.BzrAdapter
    ]

    git {
        requireBranch.set('main')
        pushToRemote.set('origin')
        pushToBranchPrefix.set('')
        commitVersionFileOnly.set(false)
        signTag.set(false)
    }

    svn {
        username.set(null)
        password.set(null)
        pinExternals.set(false)   // allows to pin the externals when tagging, requires subversion client >= 1.9.0
    }
}

Kotlin DSL Example

import net.researchgate.release.ReleaseExtension
repositories {
    maven {
      url 'https://plugins.gradle.org/m2/'
    }
  }
  dependencies {
    classpath 'net.researchgate:gradle-release:3.0.2'
  }

apply(plugin = "base")
apply(plugin = "net.researchgate.release")

configure<ReleaseExtension> {
    ignoredSnapshotDependencies.set(listOf("net.researchgate:gradle-release"))
    with(git) {
        requireBranch.set("master")
        // to disable branch verification: requireBranch.set(null as String?)
    }
}

Custom release steps

To add a step to the release process is very easy. Gradle provides a very nice mechanism for manipulating existing tasks. There are two available hooks provided: beforeReleaseBuild which runs before build and afterReleaseBuild which runs afterwards.

For example, if we wanted to make sure uploadArchives is called and succeeds after the build with the release version has finished, we would just add the uploadArchives task as a dependency of the afterReleaseBuild task:

afterReleaseBuild.dependsOn uploadArchives

Multi-Project Builds

Support for multi-project builds isn't complete, but will work given some assumptions. The gradle-release plugin assumes and expects that only one version control system is used by both root and sub projects.

Apply the plugin separately to each subproject that you wish to release. Release using a qualified task name, e.g.:

./gradlew :sub:release # release a subproject named "sub"
./gradlew :release # release the root project

Working in Continuous Integration

In a continuous integration environment like Jenkins or Hudson, you don't want to have an interactive release process. To avoid having to enter any information manually during the process, you can tell the plugin to automatically set and update the version number.

You can do this by setting the release.useAutomaticVersion property on the command line, or in Jenkins when you execute gradle. The version to release and the next version can be optionally defined using the properties release.releaseVersion and release.newVersion.

gradle release -Prelease.useAutomaticVersion=true -Prelease.releaseVersion=1.0.0 -Prelease.newVersion=1.1.0-SNAPSHOT

Getting Help

To ask questions please use stackoverflow or github issues.

To report bugs, please use the GitHub project.

gradle-release's People

Contributors

adferrand avatar bashofmann avatar chanhohang avatar christierney avatar danez avatar debuglevel avatar dkorotych avatar earthcitizen avatar eshepelyuk avatar essobedo avatar evgeny-goldin avatar friederbluemle avatar glucazeau avatar hillkorn avatar htimur avatar huxi avatar kmoens avatar leobastin avatar loosebazooka avatar martinm82 avatar mattlong-finocomp avatar mprinci2 avatar mwhipple avatar pkaila avatar quidryan avatar szpak avatar thokuest avatar townsfolk avatar vampire avatar wtfjoke 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  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  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

gradle-release's Issues

Customize branch from where release is performed

When we do a 'gradle release' task, we get the following:

:ourapp:initScmPlugin FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.

FAILURE: Build failed with an exception.

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

    Current Git branch is "integration" and not "master".

While this is great from enforcing release process ( of releases coming off master), for the sake of testing we would like to test this plugin in a separate branch. How do we customize the same ( of specifying a different branch )? Thanks !

FYI. Our build.gradle looks as below:

///////////// build.gradle begins
apply from: 'http://tellurianring.com/projects/gradle-plugins/gradle-release/apply.groovy'

allprojects {

release {
    failOnUnversionedFiles = false
    failOnUpdateNeeded = false
    useAutomaticVersion=true
}

}

task build() {

}
///////////// build.gradle ends

removes other properties in gradle.properties

Hi

With Reference to the issue 43.
I tried updating the updateVersion() method. Whether the next release has to be updated in gradle.properties. It is removing all the other properties that are defined in gradle.properties.
Can you please let me know why

Regards
Smurf

Tag created from wrong revision in svn

Hi
I tried this plugin and it updated the gradle.properties with the updated version and also created the release tag . But, once the version is updated in the gradle.properties, it does not commit that code to svn.
Can anyone please let me know, if i have missed something. Or how to implement that.
Thanks
Smurf

Check git version preconditions

Hi,

I just happened to find out that this plugin doesn't work with git 1.7.1 - it needs the git status -b option which seems to have been added in 1.7.2

You may want to add an explicit git version check to give the user a better error message in that case

Setting the SVN tag path to use

Is it possible to set the tag path to use, similar to how you can specify the tagBase configuration value in the Maven Release plugin?

The project I am working on has the following projects:

svn.company.com/repo/trunk/foo
svn.company.com/repo/trunk/foo/foo-a
svn.company.com/repo/trunk/foo/foo-b

Where foo, foo-a and foo-b are three individual projects.

The requirement is to tag them as such:

svn.company.com/repo/tags/foo-1.0
svn.company.com/repo/tags/foo-a-1.0
svn.company.com/repo/tags/foo-b-1.0

Can this release plugin handle that kind of tagging structure?

BUG when LANG!=US

When LANG=FR
svn info return "URL :" and not "URL:"

Can you execute svn info whith LANG=US ?

Tanks.

release fails if version is not stored in gradle.properties

If another versionPropertyFile is specified instead of using the default gradle.properties, the replacement of the version number fails. The ReleasePlugin's checkPropertiesFile method does this replacement:

project.ant.replace(file: propertiesFile, token: "version=${project.version}", value: "version=${project.version}", failOnNoReplacements: true, preserveLastModified: true)

The problem is that the project.version is not set unless the version is in gradle.properties or set somewhere else with some code that reads the specified version property file.

Allow overriding of the 'build' start parameter to make integrating with lifecycle tasks easier.

I would like to configure the plugin to use my own lifecycle task(s) instead of the default build task. I imagine something like this:

release {
    lifecycleTasks = [ 'releaseBuild', 'anotherTaskMaybeEmailSomeone' ]
}

I'm including part of my build script inline to show how I've set up a few lifecycle tasks and integrated them with the plugin. It seems to work quite well, but I just finished writing it, so it shouldn't be taken as an example of how to structure a build.

def majorJavaVersion = '1.7'
def exactJavaVersion = '1.7.0_17'
def runningJavaVersion = System.getProperty("java.version")

def buildTimestamp = new Date()
def buildLabelFormat = new SimpleDateFormat("yyMMddHHmmssZ")
def buildLabel = buildLabelFormat.format(buildTimestamp)

apply plugin: 'release'

release {
    // this needs to be changed if using a release branch
    requireBranch = 'master'
}

allprojects {
    ext.buildTime = buildTimestamp
}

// application updates are going to depend on the type of build being done.
// release builds belong to the stable update channel and preview builds
// belong to the preview update channel.  installers are customized based
// on the update channel set up here.
def updateChannels = [':previewBuild': 'preview', ':releaseBuild': 'stable']

gradle.taskGraph.whenReady { graph ->
    def updateChannel = 'dev' // catchall default

    updateChannels.keySet().each {
        if (graph.hasTask(it)) {
            updateChannel = updateChannels.get(it)
        }
    }

    allprojects { ext.updateChannel = updateChannel }
}

task build {
    // prevent the use of 'build' as a start parameter to give us more fine grained
    // control over the build
    gradle.taskGraph.whenReady { graph ->
        assert (!graph.hasTask(it)): "Cannot invoke 'build' directly.  Try 'devBuild'."
    }
}

task release(overwrite: true) {
    // override the release task so we can plug in the releaseBuild lifecycle task
    // instead of using 'build'
    gradle.taskGraph.whenReady { graph ->
        if(graph.hasTask(it)) {
            def releaseStartParam = gradle.startParameter.newInstance()
            releaseStartParam.setTaskNames([
                    'initScmPlugin',
                    'checkCommitNeeded',
                    'checkUpdateNeeded',
                    'unSnapshotVersion',
                    'confirmReleaseVersion',
                    'checkSnapshotDependencies',
                    'releaseBuild',
                    'preTagCommit',
                    'createReleaseTag',
                    'updateVersion',
                    'commitNewVersion'
            ])
            GradleLauncher.newInstance(releaseStartParam).run().rethrowFailure()
        }
    }
}

task updateBuildLabel << {
    allprojects {
        ext.buildTime = buildTimestamp.toString()
        ext.buildLabel =
            project.version.contains("SNAPSHOT") ? buildLabel : project.version
    }

    println "##teamcity[buildNumber '${project.ext.buildLabel}']"
}

task checkDevEnv << {
    // make sure the env is good enough to perform dev builds
    assert(runningJavaVersion.startsWith(majorJavaVersion))
}

task checkReleaseEnv << {
    // fail if the environment is wrong or if a release build was triggered without
    // using the 'release' task (the version will be unSnapshotted by the time this
    // task runs if the 'release' task was used to start the build).
    assert(runningJavaVersion.equals(exactJavaVersion))
    assert(!project.version.contains('SNAPSHOT'))
}

task devBuild {
    // some env checks, create a timestamp or release version based label, and
    // build the most dependent sub-project (an installer).  this does not run
    // any tests.
    dependsOn checkDevEnv, updateBuildLabel, ':itma-standalone-installer:i4jBuild'
}

task ciBuild {
    // an alias for the ci server
    dependsOn devBuild
}

task nightlyBuild {
    // it would be nicer to add a buildNeeded task to :itma-standalone-installer, but
    // i don't know how without using the java plugin.  this adds tests to all java
    // projects that :itma-standalone depends on.
    dependsOn ciBuild, ':itma-standalone:buildNeeded'
}

task previewBuild {
    // only start uploading installers automatically for builds that are preview
    // or better
    dependsOn nightlyBuild, ':itma-standalone-installer:i4jUpload'
}

task releaseBuild {
    // the same as preview, but with some extra env checks
    dependsOn checkReleaseEnv, previewBuild
}

// make sure no one accidentally adds a task named releaseBuild to any subprojects
subprojects {
    afterEvaluate { 
        assert(it.getTasksByName(releaseBuild.name, true).isEmpty())
    }
}

Git: Configuration requireBranch and push

If I configure requireBranch to null or '' ('' is only a problem on master, not in Version 1.2), only master will be pushed ('git push origin master' is called). Only if I also set pushToCurrentBranch to true, the current branch is pushed.

Remove usage of Eclipse JGit

Hi folks!

We ran into bug in your 1.2 version of the plugin. Shortly said, JGit does not follow symbolic links, so that every link is recognized as 'modified' by gradle-release. Please see https://github.com/eclipse/jgit#warningscaveats.

That means, non of git repository w/ symlinks can be used with plugin, except for the 'uncommited' flag turned on, and we are forced to switch to 1.1 version, where you were using native exec for 'git status --porcelain'.

Please consider removing usage of jgit, e.g. revert GitReleasePlugin.groovy to 1.1 condition.

Thanks!

A failed release only checks if gradle.properties exists even if a custom properties file is used

The check for reverting a failed release looks like:

if (releaseConvention().revertOnFail && project.file("gradle.properties")?.exists()) {
     log.error("Release process failed, reverting back any changes made by Release Plugin.")
    this.scmPlugin.revert()
} else {
    log.error("Release process failed, please remember to revert any uncommitted changes made by the Release Plugin.")
}

If a custom properties file is being used, the check should be for that file

gradle.properties is updated before the main 'build' task is run

When using the following gradle.properties:

version=0.0.1-SNAPSHOT

..and the following build.gradle:

buildscript {
    repositories {
        maven {
            url "https://oss.sonatype.org/content/groups/public/"
        }
    }
    dependencies {
        classpath 'com.github.townsfolk:gradle-release:1.2-SNAPSHOT'
    }
}

apply plugin: 'release'

task build << {
    assert(false)
}

..runing gradlew release will fail, and gradle.properties will include:

version=0.0.1

I think the version should only be updated in memory before the build task runs and updating the gradle.properties file should be done after the build task runs. Using the above example to clarify, I think project.version should be 0.0.1 while the build task is executing, but gradle.properties shouldn't be touched until just before the preTagCommit task is run.

Svn status and external link

When the project has some svn external link
The status contains some text but all files are committed.

For sample:
Running "svn status": [X doc

Performing status on external item at 'doc':
][]

Thanks.

version property for manifest entry

Hi,

for some reason

jar {
    manifest {
        attributes('Implementation-Version': version)
    }
}

still has the old value instead of the unShapshot version. project.version as well. Is there any other property or am i doing sth. wrong?

Cheers, markus

Possibility to use SNAPSHOT version of plugin

Hello, maybe I missed something but is there possibility of using plugin's SNAPSHOT, i.e. version built from latest source code or night build or similar.
Currently I have to build it myself and keeps jars in source repository for using latest changes.
It could be good addition to have possibility of using SNAPSHOT until main version is released

Unable to complete unit tests

I have cloned the gradle-release project from github and attempted to execute:

gradle clean test

The tests fail with the following output:

release.GitReleasePluginTests > should apply ReleasePlugin and GitReleasePlugin plugin FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31

release.GitReleasePluginTests > when requireBranch is configured then throw exception when different branch FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31

release.GitReleasePluginTests > should push new version to remote tracking branch by default FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31

release.GitReleasePluginTests > when pushToCurrentBranch then push new version to remote branch with same name as working FAILED
org.gradle.api.GradleException at GitReleasePluginTests.groovy:31

20 tests completed, 4 failed, 1 skipped
:test FAILED

My git versions is:
git version 1.7.11.msysgit.1

Looking in TEST-release.GitReleasePluginTests: A snippet...

org.gradle.api.GradleException: Running "git commit -m test test.txt" in [C:\Users\dwhewell\git\gradle-release\build\tmp\test\release\GitReleasePluginTestLocal] produced an error: [**\* Please tell me who you are.

Run

git config --global user.email "[email protected]"
git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'dwhewell@LHM-LAP-DEV0610.(none)')]
at release.PluginHelper.exec(PluginHelper.groovy:98)
at release.GitReleasePluginTests.setup(GitReleasePluginTests.groovy:31)

It seems that the git operations fail because the user.name and user.email are not set.

So, I run the suggested git config commands above and repeat the gradle build, with the same result.

gradle --version

Gradle 1.4

Gradle build time: Monday, 28 January 2013 03:42:46 o'clock UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.6.0_31 (Sun Microsystems Inc. 20.6-b01)
OS: Windows 7 6.1 amd64

Is there anything I should be doing to make these unit tests work? It seems as though the embedded git execs in GitReleasePluginTests.groovy prevent git from seeing .gitconfig.

SNAPSHOT as next version

Hi - is there a possibility to specify that the next version should be -SNAPSHOT automatically? If not, any chance that you can add it...?

Thanks,
Tamas

How would I replace snapshot with the git commit hash?

I'd like to set up my CI server (Jenkins) to create nightly builds, those shouldn't change the main version, but should only replace the SNAPSHOT part with the hashcode of the git commit.

How can I do that with this plugin?

Problems with --parallel

When using --parallel, the release will not work reliably. I have parallel mode enabled in my ~/.gradle/gradle.properties.

Workaround:
add a line 'tasks.release.startParameter.parallelThreadCount = 0' in your buildscript

I see two possible sollutions:

1.: in ReleasPlugin.groovy set startParameter.parallelThreadCount = 0 in definition of the release task
2.: use Task.mustRunAfter for each task.

Add upload task

Hi

I wanted to do add upload task as well in the plugin, so that it uploads to nexus repo

At present, in the release plugin, you have added a task as 'build'. I tried to add a task as 'upload', but it does not wrok. Can ou please help me on that

As you have the

Thanks
Smurf

Support for publish to repo

Apologies if this isn't the right forum, but do you know how this great plugin can be used to actually publish the release artifact? I'm using the maven-publish plugin already but what I want to be able to do is to add a call to publish in the short window where gradle release creates my non-snapshot artifact.

Synchronize plugin dependencies

Currently there's several places where plugin dependencies are declared

  • build.gradle
  • release.gradle
  • installation/apply.gradle

First of all it seems that after adoption of Sonatype apply script only should have dependency declaration of plugin itself. So gradle-git should be removed from there. Please correct me if I'm wrong

Then again we have an issue with differences between build.gradle and release.gradle. This fact will potentially bring problems to Sonatype users. For instance, release.gradle has dependency on old version of Spock and that version is used in generated Sonatype POM file.

So could you please synchronize dependencies between all gradle scripts used in plugin ? The beast approach could be moving dependencies declaration to separate file that can be included into any script that need plugin specific dependencies.

[proposal] Implementation of git functionality with JGit

Hello
I'm planning to start some work regarding migration from cmd line git client ot JGit library. This allows plugin to not depend on cmd line client and external environment.
For this I have two options

  1. Implement everything in pure JGit.
  2. Reuse gradle-git project
    Personally I prefer 2nd option because the project already provided GIT functionality as Gradle tasks, so plugin tasks could extend them to do own work. Additionally this allows us to avoid creation of some boilerplate code related to JGit.

So this questions is open and I would like to know your opinion about it before proceed.
Thank you

Problem win32 subversion 1.7

project is not problem

i was testing from svn 1.6 ( osx ) but problem is windows or subversion 1.7

plz.!!! i want to release plugin

[liongo.SF2-SEONGWOO-PC] โ†’ sh gradlew release

xxxx Poject <<<<<
0.7.4.1-GR-SNAPSHOT
:release
xxxx Poject <<<<<
0.7.4.1-GR-SNAPSHOT
:xxxxserver:initScmPlugin
:xxxxserver:checkCommitNeeded
!!WARNING!! You have 19 un-versioned files.
:xxxxserver:checkUpdateNeeded FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.

FAILURE: Build failed with an exception.

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

    Running "svn info svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver" produced an error: [svn: E670008: Unable to connect to a repository at URL 'svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver'
    svn: E670008: Unknown hostname 'developer.xxxx.co.kr']

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 8.721 secs

[liongo.SF2-SEONGWOO-PC] โ†’ svn info svn://developer.xxxxx.co.kr/svn/xx2/trunk/xxxxserver
Path: xxxxserver
URL: svn://developer.xxxx.co.kr/svn/xx2/trunk/xxxxserver
Repository Root: svn://developer.xxxxx.co.kr/svn/xx2
Repository UUID: e7335162-918b-11e0-b175-019f8cb6028d
Revision: 3418
Node Kind: directory
Last Changed Author: liongo
Last Changed Rev: 3418
Last Changed Date: 2013-06-03 20:12:59 +0900 (, 03 6 2013)

Release process should fail on error on update from remote

Currently it just ignores an error on update (here with connection timeout):

Task ':checkUpdateNeeded' has not declared any outputs, assuming that it is out-of-date.
 >>> Running [git, --git-dir=/home/foo/bar/.git, --work-tree=/home/foo/bar, remote, update]
 >>> Running [git, --git-dir=/home/foo/bar/.git, --work-tree=/home/foo/bar, remote, update]: [Fetching origin
][ssh: connect to host my.remote.host port 29418: Connection timed out
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin
]
Running "git --git-dir=/home/foo/bar/.git --work-tree=/home/foo/bar status -sb"
(...)

It would expect it to fail (but maybe there are other usecases to make it useful).

updateVersion is too fussy about format of properties file

I had spaces in my gradle.properties file, e.g.:

version = 0.0.1

This caused updateVersion to fail:

Building > :updateVersion
??> Enter the next version (current one released as [0.0.1]): [0.0.2]
:updateVersion FAILED

FAILURE: Build failed with an exception.

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

    Unable to update version property. Please check file permissions, and ensure property is in "version=0.0.2" format.

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Since this is an allowed practice in properties files it should be supported.

Wrong content on Release Tag?

Hi,

i am not sure if i am wrong, but i think the release tag has the wrong content (using SVN).

as an example:

SVN REV 200: has code with version 1.2-SNAPSHOT
-> the plugin changes to 1.2 and preTags, so we have SVN REV 201
-> the plugin builds the project and has artifacts of version 1.2
-> the plugin does the release tag but with SVN REV 200 instead of REV 201
-> the plugin does change the version to 1.3-SNAPSHOT and commits to REV 202

The issue from my perspective is, that the code living on the tag is not the code which has been release, but the code before the release.

I guess when doing the preTagCommit the result SVN Rev has to be remembered as svnRevision

Cheers, markus

Issue in gradle-release

Hi

I am working on the gradle release plugin https://github.com/townsfolk/gradle-release on the multi module project. I am able to do a svn ls url from command prompt. But this does not work.
I have mentioned the below in the main build.gradle

buildscript {
repositories {
mavenCentral()
maven { url "https://oss.sonatype.org/content/groups/public"}
}
dependencies {
classpath 'com.github.townsfolk:gradle-release:1.2'
}
}
apply plugin: 'release'

Have i missed giving the username and password for svn ?? Can you please let me know.
I tried to do a gradle release , but i am getting the following error:

:release
:svnPlatform:initScmPlugin
:svnPlatform:checkCommitNeeded FAILED
:release FAILED
Release process failed, reverting back any changes made by Release Plugin.

FAILURE: Build failed with an exception.

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

    You have 7 un-commited changes.

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debu o
    ption to get more log output.

BUILD FAILED

Thanks
Smurf

An ability to use in projects placed not in the Git repo root

I have a project which is placed not in the Git root directory (there are some other folders with scripts, docs, etc. besides the projects sources). This breaks a plugin:
``Running "git --git-dir=/home/foo/myRepo/myAppSource/.git --work-tree=/home/foo/myRepo/myAppSource branch" produced an error: [fatal: Not a git repository: '/home/foo/myRepo/myAppSource/.git']`

There could be an additional parameter to define a SCM root in a build script (e.g. scmRoot = "../").

Proper Usage of Release Plugin

I'm new to gradle and I'm looking to port my existing maven builds to gradle this year. One of the biggest requirements that I have is that we must be able to cut release builds like we do with maven today. I've been working on migrating a single project to gradle using the release plugin but it doesn't seem to work as I would expect it to. Basically, I'm looking for behavior like I have with maven today.

  1. run gradle release with a snapshot version
  2. version is updated from 1.0.0-SNAPSHOT to 1.0.0
  3. build runs and if it succeeds, 1.0.0 artifacts are tagged and published to the repo
  4. version is updated to 1.0.1-SNAPSHOT and checked in

My project has several subprojects... build.gradle looks like this. When I run the build I would expect the tagged version to have a non-snapshot version in the gradle.properties (it has the snapshot version). Also, the SNAPSHOT artifacts are published, not the 1.0.0 versioned artifacts. I'm sure that I'm doing something wrong, so any help would be appreciated!

apply from: "https://launchpad.net/gradle-release/trunk/1.0/+download/apply.groovy"
.....

uploadArchives {
def mvnUser = 'XXX'
def mvnPassword = 'YYY'
repositories.mavenDeployer {
//configuration = configurations.mavenDeployer
uniqueVersion = false
def mainPom = addFilter('main') {artifact, file -> !artifact.name.endsWith("-tests") }
def testsPom = addFilter('tests') {artifact, file -> artifact.name.endsWith("-tests") }
def poms = [ mainPom, testsPom ]
poms.each { it.version = project.version }

    repository(url: 'http://maven01.xxx.com:8080/nexus/content/repositories/releases') {
        authentication(userName: "${mvnUser}", password: "${mvnPassword}")
    }

    snapshotRepository(url: 'http://maven01.xxx.com:8080/nexus/content/repositories/snapshots') {
        authentication(userName: "${mvnUser}", password: "${mvnPassword}")
    }

}

}
release {
project.setProperty("gradle.release.useAutomaticVersion", "true");
//project.setProperty("gradle.release.unSnapshotVersion", "true");
tagPrefix = "enterprise-services-common"
preCommitText = "ESC-3 Release Build"
preTagCommitMessage = "ESC-3 Release Build"
tagCommitMessage = "ESC-3 Release Build"
newVersionCommitMessage = "ESC-3 Release Build"
}

Publish to bintray instead of tellurianring.com

I'd rather not tie the stability of my build to the uptime of an unknown website, tellurianring.com. While publishing to maven central would be ideal, it's a PITA. bintray (from JFrog) is a real easy alternative, which is easy to publish to, and easy to pull from.

The system of doing an apply from to a http URL is a source of problems (e.g. it can't be cached by Gradle, and no offline mode), and a security vector. We'd much prefer to have the raw apply plugin in our build scripts, but that's only possible if we also have the repository already setup.

Update version fails silently if gradle.properties contains spaces in the version assignment.

I'm using version 1.2 of the plugin.

If the version assignment used in gradle.properties contains spaces around the = sign, the release plugin will silently fail to update the version number. Everything looks like it works, but the version never gets changed. It also makes the commits in Git look a bit wonky.

I've run into the same thing before filtering properties files with Gradle and I still have a warning in the comments at the top of the file, so I'm not sure how to fix it.

To clarify, version=0.0.1-SNAPSHOT works, but version = 0.0.1-SNAPSHOT fails.

The plugin works very well for me BTW. It's nice and simple (to use).

Why is release task GradleBuild type?

Hi,

While executing the release task, I noticed 2 things:

  • most dependent tasks are executed twice
  • I set an ext property based on gradle.startParameter.taskNames.contains('release'), but this property gets lost during the release task because it runs in a new context with a new startParameter

So my question: is there a specific reason why the release task has type GradleBuild i.s.o. being a plain task that depends on other tasks?

Ivo

An ability to disable push to remote repo on release

It is sometimes useful to have a full control over interaction with remote error on release process. There could be an additional flag (pushChanges? - default true) which would allow to review changes done by a release plugin before (manual) push.

To support TeamCity release project with gradle-release plugin

Hi,

Thanks for the plugin to facilitate my development work. Can make the gradle-release plugin support TeamCity ? Currently I do some special handing in build.grade to make "gradle install" can build in teamcity, and the "gradle release" only work in local PC which have svm folder, such as ".git", which TeamCity work directory don't have!

Jenkins

Hi

Has this plugin been tested in jenkins?
Thanks
Smurf

Configurable prefix for release tag

It could be good addition to allow configure release tag prefix via plugin convention properties.
Currently it's possible to use project name for prefixing tag but could be something like

release {
releaseTagPrefix = 'MY_PREFIX_'
}

So all tags created will look like MY_PREFIX_1.2.3

Asking for version numbers using System.console.readLine()

My primary development environment is Windows with a Cygwin command line.

Sadly, System.console in Cygwin returns null. It's a known issue, but there isn't a direct work around other than working around it. Our project uses your plugin, but this means I cannot do a release in Cygwin. Could you modify your readLines() to do something such as

http://stackoverflow.com/questions/4203646/system-console-returns-null

for more cross environment compatibility?

MIgration to jGit - final steps

Hello

  1. For proper work of gradle-release we need to use version 0.5.0 of gradle-git. Please upgrade
  2. Could you announce when SNAPSHOT or release version of plugin will be available. So we can switch from custom jar to published version. ?

Sorry for inconveniences brought by my pull request.

Improvements for usage in CI environment

Thanks for providing this plugin! I'm currently using it for a couple of our projects (java/war multi-project builds, SVN, jenkins).

I had to make a couple of adjustments to leverage this plugin:

  • Support for multiple SVN locations on jenkins: our jenkins jobs contain multiple SVN locations (the [root] project directory, a directory with libs etc.). It seems that the SVN commands are executed in the (jenkins) workspace root which leads to a svn: '.' is not a working copy directory error.
    I adjusted the exec methods to use project.getProjectDir() which solved the issue (this also works locally)
  • Provide SVN password: some of the SVN operations seem to wait for the user to provide the password which doesn't work in a CI environment. Since I don't have SSH access to the CI machine I added the password to the code. Maybe this could be refactored to the plugin convention so the user (build master) can configure the SVN password in build.gradle.

What do you think about those 2 points? If a find time I'll issue a pull request.

I also struggled with issue 27, so it might be helpful to include this in the readme.
Looking ahead it might be useful to be able to provide the release version and the next version (compared to the local execution) in a CI environment as well (for instance provided by the jenkins release plugin).

Best,

Moritz

Question: Put plugin jars to GitHub and release minor version

Hello

For further migration to GitHub it could be useful to put plugin jar to download section and update README to configure downloading of plugin from GitHub instead of Launchpad.

Also maybe you can consider releasing minor version of plugin with couple of fixes introduced by latest changes

What do you think ?

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.