stianh / gradle-release-plugin Goto Github PK

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.

Add an option failOnSnapshotDependencies which by default is true

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.

The plugin should really be built by the oldest gradle version possible. This makes it usable for more people.

To ensure that the plugin will work even if Git is not installed.

Initially, deploying to Sonatype OSS Maven repository meant that the packaging had to be specified even when jar packaging is the default. Is still the case?

Some might prefer to do the tagging manually. The plugin should then use the version found by "git describe", and ensure that there are no commits (and local changes) since the last tag.

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.

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?

Look at the Java library which implements most of the Semantic Versioning specification.

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

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.

Hi,

please add a LICENSE file to this project so people can easily spot it.

Implemented by using something like project.rootProject.hasPlugin(...) and project.rootProject == project

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)

Plugin does not support searching upwards for the .git directory.

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.

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"

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

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

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?

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."

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

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?

Hello
Have you considered existing release plugin(s)
For example this one - is quite usable
http://tellurianring.com/wiki/gradle/release
Does this plugin do some other job ?

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?

Add a svnrelease plugin to support releasing with Subversion.

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?

By setting a system property like:

-Drelease.version=1.12

the plugin should use this version directly without any calculation.

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

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/'.

The fix for GH-17 entailed checking the task graph for releasePrepare being present before
checking for snapshots. The problem was that the task graph was not always populated right
after a configuration resolve, which is when the check is done.

Instead move the SNAPSHOT checking into a hook that gets executed when all dependencies are resolved.

When doing a regular build of a project with snapshot dependencies,
the plugin fails the build. It should only fail the build if any
snapshot dependencies exist when releasing.

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