stianh / gradle-release-plugin Goto Github PK
View Code? Open in Web Editor NEWGradle plugin for automated release management.
Gradle plugin for automated release management.
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.
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:
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
releasePerform
*** svn
releasePrepare
releasePerform
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.