• Stars
    star
    211
  • Rank 186,867 (Top 4 %)
  • Language
    Groovy
  • License
    Apache License 2.0
  • Created about 10 years ago
  • Updated over 1 year ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Release opinions based around gradle-git

nebula-release-plugin

Support Status Gradle Plugin Portal Maven Central Build Apache 2.0

This plugin provides opinions and tasks for the release process provided by gradle-git.

Optional Configuration

If you want the release plugin to trigger or finalize a publishing task you will need to configure it:

tasks.release.dependsOn tasks.<publish task name>

-or-

tasks.release.finalizedBy tasks.<publish task name>

This plugin also detects the presence of the nebula-bintray-plugin and wires itself to depend on the task types used by bintrayUpload and artifactoryUpload.

Opinions

Project using this plugin will use semantic versions style strings. e.g. major.minor.patch-<prerelease>+<metadata>

All tasks default to bumping the minor version.

Extension Provided

nebulaRelease {
  Set<String> releaseBranchPatterns = [/master/, /HEAD/, /main/, /(release(-|\/))?\d+(\.\d+)?\.x/, /v?\d+\.\d+\.\d+/] as Set
  Set<String> excludeBranchPatterns = [] as Set
  String shortenedBranchPattern = /(?:(?:bugfix|feature|hotfix|release)(?:-|\/))?(.+)/

  void addReleaseBranchPattern(String pattern)
  void addExcludeBranchPattern(String pattern)
}
Property Type Default Description
releaseBranchPatterns Set<String> [master, HEAD, main, (release(-|\/))?\d+(\.\d+)?\.x, v?\d+\.\d+\.\d+] Branch patterns that are acceptable to release from. The default pattern will match things like master, 1.2.x, release-42.x, release/2.x, v1.2.3. If the set is empty releases will be possible from any branch that doesn't match excludeBranchPatterns.
excludeBranchPatterns Set<String> [] Branch patterns that you cannot release from. If a branch matches both releaseBranchPatterns and excludeBranchPatterns it will be excluded.
shortenedBranchPattern String (?:(?:bugfix|feature|hotfix|release)(?:-|\/))?(.+) Branch widget1 will append widget1 to snapshot version numbers, and branch (feature|bugfix|release|hotfix)/widget2 will append widget2 to snapshot version numbers. You may configure this field, the regex is expected to have exactly one capture group.
Method Arguments Description
addReleaseBranchPattern String pattern Calling this method will add a pattern to the set of releaseBranchPatterns, usage: nebulaRelease { addReleaseBranchPattern(/myregex/)
addExcludeBranchPattern String pattern Calling this method will add a pattern to the set of excludeBranchPatterns, usage: nebulaRelease { addExcludeBranchPattern(/myregex/)

Tasks Provided

All tasks will trigger gradle-git's release task which is configured to depend on the build task if the project produces JVM based jar or war artifacts.

  • final - Sets the version to the appropriate <major>.<minor>.<patch>, creates tag v<major>.<minor>.<patch>
  • candidate - Sets the version to the appropriate <major>.<minor>.<patch>-rc.#, creates tag v<major>.<minor>.<patch>-rc.# where # is the number of release candidates for this version produced so far. 1st 1.0.0 will be 1.0.0-rc.1, 2nd 1.0.0-rc.2 and so on.
  • devSnapshot - Sets the version to the appropriate <major>.<minor>.<patch>-dev.#+<hash>, does not create a tag. Where # is the number of commits since the last release and hash is the git hash of the current commit. If releasing a devSnapshot from a branch not listed in the releaseBranchPatterns and not excluded by excludeBranchPatterns the version will be <major>.<minor>.<patch>-dev.#+<branchname>.<hash>
    • You can use nebula.release.features.replaceDevWithImmutableSnapshot=true in your gradle.properties file to change pattern of version to <major>.<minor>.<patch>-snapshot.<timestamp>+<hash>. Where timestamp is UTC time in YYYYMMddHHmm format, ex. 201907052105 and hash is the git hash of the current commit. If releasing a immutableSnapshot from a branch not listed in the releaseBranchPatterns and not excluded by excludeBranchPatterns the version will be <major>.<minor>.<patch>-snapshot.<timestamp>+<branchname>.<hash>
  • snapshot - Sets the version to the appropriate <major>.<minor>.<patch>-SNAPSHOT, does not create a tag.

Use of devSnapshot vs snapshot is a project by project choice of whether you want maven style versioning (snapshot) or semantic versioned snapshots (devSnapshot).

Versioning Notes

We attempt to pick up on the fact that you're on certain release branches.

Examples:

  • On release/1.x - The plugin will default to versioning you 1.0.0-SNAPSHOT
  • On 3.x - The plugin will default to versioning you 3.0.0-SNAPSHOT
  • On 4.2.x - The plugin will default to versioning you 4.2.0-SNAPSHOT

Releasing: Bumping major or patch versions

There are many cases where a project may want to bump a part of the version string besides the minor number.

  • bump the major number: ./gradlew <snapshot|devSnapshot|candidate|final> -Prelease.scope=major
  • bump the patch number: ./gradlew <snapshot|devSnapshot|candidate|final> -Prelease.scope=patch

Releasing: Using last tag

In the scenario, where the tag is already created but you want to go through the release process, you can use the "Last Tag Strategy". When enabled, the plugin will respect the last tag as the version. This works well in a CI environment where a user will tag the code, and CI is configured to do just the release upon finding a new tag. The tag names need to follow the versioning scheme, e.g. "v1.0.1". To enact, provide the release.useLastTag project property, e.g.

git tag v1.0.0
./gradlew -Prelease.useLastTag=true final

Overriding version from the command line

To set the version from the command line, set the release.version system property:

./gradlew -Prelease.version=1.2.3 final

Caveats

First release with this plugin

If this is the first time releasing with this plugin and you've released in the past you may need to create a tag in your repository. You should find the hash of your latest release and create a tag of the format v<major>.<minor>.<patch> e.g. v1.4.2. For example, if the hash of your last release was da5d4f9:

git tag v1.4.2 da5d4f9
git push --tags
./gradlew final

Initial version not 0.1.0 or 1.0.0

This will create a tag v<string> where String is whatever you set on release.version. If you want the plugin to work from here on out you should choose a version that matches semantic versioning described above.

./gradlew -Prelease.version=42.5.0 final

Git root is in a different location from Gradle root

The plugin assumes Git root is in the same location as Gradle root. If this isn't the case, you may specify a different path for Git root via the git.root Gradle property. For example:

./gradlew -Pgit.root=<git root path> final

Sanitize versions

Historically, this plugin generated versions using build metadata which comes after the + sign. While we suggest using this approach to be semver compliant, some people has raised their need for removing the build medata and make it part of the pre-release string.

For this, starting on version 11.0.0 we have introduced a sanitizeVersion flag. Ex.

./gradlew -Prelease.sanitizeVersion=true devSnapshot

This will generate a version string similar to: 0.1.0-dev.2.e1c43c7

Please note that now the build metadata is part of the pre-release information and could affect how versions are handled by a SemVer library/tool.

Lifecycle Hooks

For devSnapshot

  • devSnapshotSetup - any kind of setup is good to live around here, e.g. setting status, various checks
  • release - probably have release dependOn any assemble and check tasks, dependsOn devSnapshotSetup
  • postRelease - any steps you want to happen after the repo tag, in our case this is where publishing happens since if the publish partially fails we don't want to fix the tags, dependsOn release
  • devSnapshot - command line task to kick off devSnapshot workflow, dependsOn postRelease

For snapshot

  • snapshotSetup - any kind of setup is good to live around here, e.g. setting status, various checks
  • release - probably have release dependOn any assemble and check tasks, dependsOn snapshotSetup
  • postRelease - any steps you want to happen after the repo tag, in our case this is where publishing happens since if the publish partially fails we don't want to fix the tags, dependsOn release
  • snapshot - command line task to kick off snapshot workflow, dependsOn postRelease

For candidate

  • candidateSetup - any kind of setup is good to live around here, e.g. setting status, various checks
  • release - this is where the tag is pushed to the repo, so probably have release dependOn any assemble and check tasks, dependsOn candidateSetup
  • postRelease - any steps you want to happen after the repo tag, in our case this is where publishing happens since if the publish partially fails we don't want to fix the tags, dependsOn release
  • candidate - command line task to kick off candidate workflow, dependsOn postRelease

For final

  • finalSetup - any kind of setup is good to live around here, e.g. setting status, various checks
  • release - this is where the tag is pushed to the repo, so probably have release dependOn any assemble and check tasks, dependsOn finalSetup
  • postRelease - any steps you want to happen after the repo tag, in our case this is where publishing happens since if the publish partially fails we don't want to fix the tags, dependsOn release
  • final - command line task to kick off final workflow, dependsOn postRelease

Gradle and Java Compatibility

Built with OpenJDK8 Tested with OpenJDK8

Gradle Version Works
5.0 yes
5.1 yes
5.2 yes
5.3 yes
5.4 yes
5.5 yes

LICENSE

Copyright 2014-2019 Netflix, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

More Repositories

1

gradle-lint-plugin

A pluggable and configurable linter tool for identifying and reporting on patterns of misuse or deprecations in Gradle scripts.
Groovy
680
star
2

gradle-ospackage-plugin

Gradle plugin for constructing linux packages, specifically RPM and DEBs.
Groovy
358
star
3

gradle-dependency-lock-plugin

A plugin to allow people using dynamic dependency versions to lock them to specific versions.
Groovy
286
star
4

gradle-extra-configurations-plugin

Gradle plugin introducing a provided dependency configuration and marking a dependency as optional.
Groovy
138
star
5

nebula-publishing-plugin

Publishing related plugins
Groovy
93
star
6

nebula-project-plugin

Healthy defaults for a standard Gradle project
Groovy
87
star
7

nebula-dependency-recommender-plugin

Leave off version numbers in your dependencies section and have versions recommended by several possible sources.
Groovy
69
star
8

gradle-metrics-plugin

Plugin to send Gradle metrics to external datasources
Java
66
star
9

nebula-kotlin-plugin

Provides the Kotlin plugin via the Gradle plugin portal, automatically depends on the standard library, and allows Kotlin library versions to be omitted
Groovy
57
star
10

gradle-info-plugin

Plugin to gather information about the environment
Groovy
47
star
11

nebula-test

Test harness for Gradle plugins
Groovy
43
star
12

gradle-resolution-rules-plugin

Gradle plugin for providing reusable dependency resolution rules.
Groovy
41
star
13

gradle-java-cross-compile-plugin

Automatic configuration of bootstrap classpath for Java, Groovy and Kotlin.
Kotlin
27
star
14

gradle-aggregate-javadocs-plugin

Provides the ability to aggregate Javadocs across all projects in a multi-project build.
Shell
25
star
15

nebula-docker-plugin

Plugin to help with assembling Docker images from Java apps in the context of using Nebula
Groovy
21
star
16

gradle-override-plugin

Override arbitrary properties in a Gradle build
Groovy
21
star
17

nebula-clojure-plugin

Plugin providing Clojuresque with compatibility fixes for Gradle 2.12 and later
Groovy
18
star
18

nebula-core

Classes common to other nebula plugins
Groovy
18
star
19

gradle-stash-plugin

Various tasks for interacting with the Stash SCM
Groovy
18
star
20

nebula-bintray-plugin

Bintray Tasks
Groovy
17
star
21

gradle-netflixoss-project-plugin

Gradle plugin to setup common needs for Netflix OSS projects
Groovy
16
star
22

nebula-ospackage-plugin

Opinionated plugins that wrap the gradle-ospackage-plugin
Groovy
16
star
23

nebula-plugin-plugin

Plugin for plugins, heavily opinionated about nebula-plugins
Groovy
15
star
24

gradle-jakartaee-migration-plugin

Provides Gradle capabilities and transforms to ease the migration from Java EE to Jakarta EE
Kotlin
15
star
25

gradle-git-scm-plugin

Git implementation of gradle-scm-plugin
Groovy
14
star
26

gradle-blacklist-plugin

Failing builds with bad dependencies. Replacing bundles, etc.
Groovy
14
star
27

gradle-contacts-plugin

Structure to define the owners of a project, then contributing this back to other plugins
Groovy
12
star
28

gradle-resolution-rules

Rules for the Resolution Rules plugin
Groovy
11
star
29

gradle-scm-plugin

Base SCM Plugin for gathering information or performing actions
Groovy
9
star
30

example-multiproject

An example multiproject demonstrating how we use the nebula plugins
Java
7
star
31

nebula-node-plugin

Groovy
6
star
32

ensure

Scripts to ensure Github is properly configured for this project
Groovy
5
star
33

nebula-interactive

JavaScript
5
star
34

gradle-rxjava-project-plugin

Gradle plugin to introduce conventions of a ReactiveX projects
Groovy
5
star
35

gradle-nothing-plugin

Literally does nothing. Used for testing gradle-plugin-plugin
Groovy
4
star
36

nebula-hollow-plugin

Java
4
star
37

lock-experimental

Experimental major overhaul of https://github.com/nebula-plugins/gradle-dependency-lock-plugin
Kotlin
4
star
38

nebula-plugins.github.io

JavaScript
3
star
39

example-project

An example project on how we use the nebula plugins on a simple project
Java
3
star
40

nebula-gradle-interop

Kotlin library providing extensions to assist with Gradle iterop and backwards compatibility
Groovy
2
star
41

lazybones-nebula-plugin-template

A lazybones template for creating new nebula plugins
Groovy
2
star
42

gradle-warnings-plugin

Allows for defining and emitting warnings.
Groovy
2
star
43

nebula-dependency-base-plugin

Kotlin
2
star
44

nebula-grails-plugin

Fork of the Grails 2.x Gradle plugin providing later Gradle version and plugin portal support.
Groovy
2
star
45

buildscan-test

Shell
1
star
46

nebula-oss-publishing-plugin

Publishes nebula projects to Netflix OSS repositories and Maven Central
Kotlin
1
star
47

nebula-blob-plugin

Copy files to S3 using Gradle FileSpec
Groovy
1
star