All Projects → gladed → Gradle Android Git Version

gladed / Gradle Android Git Version

Licence: apache-2.0
A gradle plugin to calculate Android-friendly version names and codes from git tags

Programming Languages

groovy
2714 projects

Projects that are alternatives of or similar to Gradle Android Git Version

gradle-semantic-build-versioning
Gradle plugin to generate version-numbers and tags using semantic versioning
Stars: ✭ 19 (-91.63%)
Mutual labels:  gradle-plugin, versioning
Maven Git Versioning Extension
This extension will virtually set project versions, based on current git branch or tag.
Stars: ✭ 178 (-21.59%)
Mutual labels:  gradle-plugin, versioning
Axion Release Plugin
Gradle release & version management plugin.
Stars: ✭ 372 (+63.88%)
Mutual labels:  gradle-plugin, versioning
Versionberg
Gradle plugin for versioning your library/application on every git commit
Stars: ✭ 78 (-65.64%)
Mutual labels:  gradle-plugin, versioning
gradle-git-versioning-plugin
This extension will set project version, based on current Git branch or tag.
Stars: ✭ 44 (-80.62%)
Mutual labels:  gradle-plugin, versioning
Reckon
Infer a project's version from your Git repository.
Stars: ✭ 124 (-45.37%)
Mutual labels:  gradle-plugin, versioning
Versioning
Gradle plug-in to generate version information from the SCM branch (Git or Svn)
Stars: ✭ 157 (-30.84%)
Mutual labels:  gradle-plugin, versioning
Vue Kotlin
Libraries and tools supporting the use of Vue.js in Kotlin.
Stars: ✭ 162 (-28.63%)
Mutual labels:  gradle-plugin
Ansible Silo
Ansible in a self-contained environment via Docker.
Stars: ✭ 183 (-19.38%)
Mutual labels:  versioning
Gitversion
From git log to SemVer in no time
Stars: ✭ 2,131 (+838.77%)
Mutual labels:  versioning
Hatch
A modern project, package, and virtual env manager for Python
Stars: ✭ 2,268 (+899.12%)
Mutual labels:  versioning
Gradle Testsets Plugin
A plugin for the Gradle build system that allows specifying test sets (like integration or acceptance tests).
Stars: ✭ 182 (-19.82%)
Mutual labels:  gradle-plugin
Retropiler
PoC of Java8 Standard Library for Android for API version >= 15
Stars: ✭ 159 (-29.96%)
Mutual labels:  gradle-plugin
Aspnet Api Versioning
Provides a set of libraries which add service API versioning to ASP.NET Web API, OData with ASP.NET Web API, and ASP.NET Core.
Stars: ✭ 2,154 (+848.9%)
Mutual labels:  versioning
Jarfilterplugin
Help exclude classes before building the JAR into Android DEX archives.
Stars: ✭ 189 (-16.74%)
Mutual labels:  gradle-plugin
Version
Represent and compare versions via semantic versioning (SemVer) in Swift
Stars: ✭ 160 (-29.52%)
Mutual labels:  versioning
Gradle Errorprone Plugin
Gradle plugin to use the error-prone compiler for Java
Stars: ✭ 202 (-11.01%)
Mutual labels:  gradle-plugin
Badass Jlink Plugin
Create a custom runtime image of your modular application
Stars: ✭ 216 (-4.85%)
Mutual labels:  gradle-plugin
Gradle Launch4j
A gradle-plugin to create windows executables with launch4j
Stars: ✭ 177 (-22.03%)
Mutual labels:  gradle-plugin
Gradle Swagger Generator Plugin
Gradle plugin for OpenAPI YAML validation, code generation and API document publishing
Stars: ✭ 197 (-13.22%)
Mutual labels:  gradle-plugin

gradle-android-git-version

CircleCI

A gradle plugin to calculate Android-friendly version names and codes from git tags.

If you are tired of manually updating your Android build files for each release, or generating builds that you can't trace back to code, then this plugin is for you!

Installation and Use

1. Add the plugin to your project

Add plugins block to the top of your app/build.gradle (or equivalent):

plugins {
    id 'com.gladed.androidgitversion' version '0.4.14'
}

2. Set versionName and versionCode from plugin results

android {
    // ...
    defaultConfig {
        // ...
        versionName androidGitVersion.name()
        versionCode androidGitVersion.code()

3. Use a git tag to specify your version number (see Semantic Versioning)

$ git tag 1.2.3
$ gradle --quiet androidGitVersion
androidGitVersion.name	1.2.3
androidGitVersion.code	1002003

For more advanced usage, read on...

Tag format

Tags should look like 1 or 3.14 or 1.12.5. There must be at least one tag of this format reachable from the current commit, or the generated version name will be "unknown".

Any suffix after the version number in the tag (such as -release4 in 1.2.3-release4) is included in the version name, but is ignored when generating the version code.

In some cases, you'll have more than one version being generated in a single repo. In this case you can supply a prefix like "lib-" to separate sets of tags. See prefix below for more.

Intermediate Versions

Builds from non-tagged commits will generate a name() something like this:

1.2.3-2-93411ff-fix_issue5-dirty

In the example above, the components are:

1.2.3 -2 -93411ff -fix_issue5 -dirty
Most recent tag Number of commits since tag Commit SHA prefix Branch name Dirty indicator

Branches listed in hideBranches won't appear.

"-dirty" will only appear if the current branch has uncommitted changes.

You can customize this layout with format (see below).

Version Codes

Version codes are calculated relative to the most recent tag. For example, version 1.2.3 will have a version code of 1002003.

You can customize the scheme used to generate version codes with codeFormat (see below).

Methods

name() returns the current version name.

code() returns the current version code.

flush() flushes the internal cache of information about the git repo, in the event you have a gradle task that makes changes to the repo.

Tasks

androidGitVersion prints the name and code, as shown above.

androidGitVersionName prints only the name.

androidGitVersionCode prints only the code.

Usage Notes

  • To save on bandwidth, CI servers may default to a "shallow" clone of your repo having no revision history, or may omit the pulling of tags. This hides the commit history and will prevent this plugin from accurately identifying the name or version code. This will result in an error not seen on your local build machine:

    Building app with versionName [untagged_814fca9-812f...9b8], versionCode [0]
    

    To address this, configure your CI project to pull enough history (e.g. git fetch --depth=100 --tags) to reach recent commits and tags of interest.

  • git worktree is not supported.

Configuration Properties

You can configure how names and codes are generated by adding an androidGitVersion block to your project's build.gradle file, before the android block. For example:

androidGitVersion {
    abis = ["armeabi":1, "armeabi-v7a":2 ]
    baseCode 200000
    codeFormat 'MNNPPP'
    commitHashLength = 8
    format '%tag%%.count%%<commit>%%-branch%%...dirty%'
    hideBranches = [ 'develop' ]
    onlyIn 'my-library'
    prefix 'lib-'
    tagPattern(/^R[0-9]+.*/)
    untrackedIsDirty = false
}

android {
    // ...
}

abis (map of String:int)

abis indicate how ABI platforms are mapped to integer codes. These integer codes are inserted into the A place in codeFormat.

The default abis are:

['armeabi':1, 'armeabi-v7a':2, 'arm64-v8a':3, 'mips':5, 'mips64':6, 'x86':8, 'x86_64':9 ]

baseCode (int)

baseCode sets a floor for all generated version codes (that is, it is added to all generated version codes). Use this when you have already released a version with a code, and don't want to go backwards.

The default is baseCode 0, enforcing no minimum version code value.

codeFormat (string)

codeFormat defines a scheme for building the version code. Each character corresponds to a reserved decimal place in the resulting code:

  • M for the Major version number (1.x.x)
  • N for the Minor version number (x.1.x)
  • P for the Patch version number (x.x.1)
  • R for the Revision number (e.g. x.x.x-rc1)
  • B for the build number (revisions since last tag)
  • A for the ABI platform code [1]
  • X for a blank place filled with 0

[1] if you use A you must call variants to tell the plugin about your project's build variants. For example:

android {
    ...
    androidGitVersion {
        codeFormat = 'AMNNPPP'
        variants applicationVariants
    }
}

Note that changing the version code scheme for a released Android project can cause problems if your new version code does not increase monotonically. Consider baseCode if you are changing code formats from a prior release.

Android version codes are limited to a maximum version code of 2100000000. As a result, codeFormat only allows you to specify 9 digits.

The default is codeFormat 'MMMNNNPPP', leaving 3 digits for each portion of the semantic version. A shorter code format such as MNNPPP is highly recommended.

commitHashLength (int)

commitHashLength specifies how many characters to use from the beginning of commit SHA hash (e.g. commit in format). Values from 4 to 40 are valid.

The default length is 7 (similar to git describe --tags).

hideBranches (list of strings/regexes)

hideBranches identifies branch names to be hidden from the version name for intermediate (untagged) commits.

For example, if 'master' is your development branch, hideBranches ['master'] results in build names like 1.2-38-9effe2a instead of 1.2-38-master-9effe2a.

Note that each element of hideBranches is interpreted as a regex pattern, for example, [ 'master', 'feature/.*' ].

The default is hideBranches [ 'master', 'release' ], meaning that intermediate builds will not show these branch names.

format (string)

format defines the form of the version name.

Parts may include:

  • tag (the last tag)
  • count (number of commits, if any, since last tag)
  • commit (most recent commit prefix, if any, since the last tag)
  • branch (branch name, if current branch is not in hideBranches)
  • dirty (inserting the word "dirty" if the build was made with uncommitted changes).
  • describe (the string generated by git.describe, similar to the output from git describe --tags. Warning: This command works differently from the rest of this plugin and result in different tag, count, or commit parts than those used to generate the version code.)

Parts are delimited as %<PARTNAME>%. Any other characters appearing between % marks are preserved.

Parts are sometimes omitted (such as a branch name listed by hideBranches). In this case the entire part will not appear.

The default is format "%tag%%-count%%-commit%%-branch%%-dirty%"

onlyIn (string)

onlyIn sets a required path for relevant file changes. Commits that change files in this path will count, while other commits will be ignored for versioning purposes.

For example, consider this directory tree:

+-- my-app/
    +-- .git/
    +-- build.gradle
    +-- app/
    |   +-- build.gradle
    |   +-- src/
    +-- lib/
        +-- build.gradle
        +-- src/

If my-app/lib/build.gradle is configured with onlyIn 'lib', then changes to files in other paths (like my-app/build.gradle or my-app/app/src) will not affect the version name.

The default is onlyIn '', including all paths.

prefix (string)

prefix sets the required prefix for any relevant version tag. For example, with prefix 'lib-', the tag lib-1.5 is used to determine the version, while tags like 1.0 and app-2.4.2 are ignored. When found, the prefix is removed from the front of the final version name.

The default is prefix '', matching all numeric version tags.

tagPattern (string/regex)

tagPattern limits the search for the most recent version tag to those that match the pattern. For example, tagPattern(/^v[0-9]+.*) limits matches to tags like v1.6.

If both prefix and tagPattern are used, the prefix strings should be included in the tagPattern.

The default is tagPattern(/^$prefix[0-9]+.*/), finding all tags beginning with the prefix (if specified) and a digit.

untrackedIsDirty (boolean)

When untrackedIsDirty is true, a version is considered dirty when any untracked files are detected in the repo's directory.

The default is untrackedIsDirty false; only tracked files are considered when deciding on "dirty".

Deprecated Configuration Properties

See DEPRECATED.md.

Version History

See HISTORY.md.

License

All code here is Copyright 2015-2019 by Glade Diviney, and licensed under the Apache 2.0 License.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].