ajoberstar / reckon Goto Github PK

This could be used for an alternate Git impl and to support many (most) other VCS systems.

current mockup

reckon {
  normal {
    scopeSysProp()
  }
  preRelease {
    stageSysProp('dev', 'milestone', 'rc')  
  }
  vcsInventory {
    grgit(project.grgit) // default to pulling from this
  }
}

I would like to use semver-vcs-gradle-grgit to implement semantic versioning in a way that entire versioning process bases on git tags (read from GitHub). Something of this sort

$ git tag
0.1.0
$ gradle properties | grep version
version: 0.1.1.dev.1
$ gradle release -Prelease.scope=minor -Prelease.stage=final
...
$ git tag
0.1.0
0.2.0
$ gradle properties | grep version
version: 0.2.1.dev.1

With a snippets of code that I wrote, I am facing

Inferred version (0.1.0-dev.1) must have higher precedence than previous (1.0.0-SNAPSHOT)

but I am not even sure if the direction is correct. Some guidance is highly welcomed. This is a snipped of groovy:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.ajoberstar:semver-vcs-gradle-grgit:0.1.0-milestone.1"
    classpath "org.ajoberstar:grgit:1.3.0"
  }
}

apply plugin: 'org.ajoberstar.release-opinion'
apply plugin: 'org.ajoberstar.semver-vcs-grgit'

import org.ajoberstar.grgit.Grgit
import org.ajoberstar.gradle.git.release.opinion.Strategies

release {
  grgit = Grgit.open(project.file('.'))
  versionStrategy Strategies.FINAL
  def strategy = Strategies.SNAPSHOT
  strategy = strategy.copyWith(createTag: true)
  defaultVersionStrategy = strategy
  tagStrategy {
    prefixNameWithV = false // defaults to true
    generateMessage = { version -> "Released by $user" }
  }

Should we force the Vcs to cache, or should we be more sparing about how often we call Vcs methods? Maybe just create a cached wrapper that calls everything once and pass that along.

I tried reckon 0.3.0 on a project having the following tags:

v0.3
v0.4
v0.4.1
v0.5
v0.5.1
v0.5.2

based on the intructions on the Readme.md. However, I do not get the expected reckon output. I think it would be good to document (say, two examples) what kind of tags the project expects by default.

Might be too restrictive or too magical.

I was trying to figure out what the initial version of the project should be set to. I created a tag called 0.0.0 and added the plugin without any version details. But that failed with the following error.

No signature of method: org.ajoberstar.reckon.gradle.ReckonPlugin$DelayedVersion.trim() is applicable for argument types: () values: []

Here is how I am using the plugin,

plugins {
    id 'org.ajoberstar.grgit' version '2.1.1'
    id 'org.ajoberstar.reckon' version '0.4.0'
}

apply plugin: 'java'

group = 'xxxxxx'
//version = '0.0.0'

reckon {
    normal = scopeFromProp()
    // preRelease = snapshotFromProp()
}


task printVersionDetails() {
    doLast() {
        println 'Project version is set to: ' + project.getVersion()
    }
}

gradle printVersion -Preckon.scope=patch

Can you please tell me how I should use the plugin? I am a little lost and not sure where the version should be defined.

Environment

Gradle 4.6
Build time:   2018-02-28 13:36:36 UTC
Revision:     8fa6ce7945b640e6168488e4417f9bb96e4ab46c
Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          1.8.0_162 (Oracle Corporation 25.162-b12)
OS:           Mac OS X 10.13.3 x86_64

Address common parallel development use cases, such as GitFlow, as described in ajoberstar/gradle-git#115 and supporting pull requests.

This may involve branch's providing constraints on what versions can be in them, and essentially claiming a set of versions that can't be used in other branches.

Have some tests that verify that the performance of the inventory supplier is acceptable.

Parallel versions behavior may be too aggressive right now.

How the version is inferred is of use to users.

Hello,

How can I make reckon generate insignificant versions when supplying an (empty) stage ?

I'm using reckon to build continuous integration with Jenkins Pipeline via Jenkinsfile and I (believe I) need it to generate insignificant versions when not supplying a scope.

I have configured reckon like this:

reckon {
    normal = scopeFromProp()
    preRelease = stageFromProp('dev', 'rc', 'final')
}

And in my Jenkinsfile I have something like this:

pipeline {
  agent any
  environment { }
  parameters {
    string(name: 'releaseScope', defaultValue: 'minor', description: 'Reckon (gradle plugin) release scope.')
    string(name: 'releaseStage', defaultValue: 'dev', description: 'Reckon (gradle plugin) release stage.')
  }

  stages {
    stage('Checkout') {     steps {    checkout scm    }    }

    stage('Build'){
      steps {
        echo "Building... ${env.BRANCH_NAME}"
        sh "./gradlew clean build -Preckon.scope=${params.releaseScope} -Preckon.stage=${params.releaseStage} --stacktrace"
      }
    }

The issue that I'm having is that with default build triggering, the stage is set to 'dev' and that creates a significant version with a tag and everything, which is not something I wish to have when building non-final versions.

I run it the build with the above configuration, this is executed:

./gradlew clean build -Preckon.scope=minor -Preckon.stage=dev --stacktrace

It gives me a version like this 1.8.0-dev.1 .

I have tried not to supply the stage, or supply an empty string but it does not work:

./gradlew clean build -Preckon.scope=minor -Preckon.stage= --stacktrace
.....
Stage "" is not one of: [rc, dev, final]

Thank you,

p.s. You're awesome for making reckon and all the other stuff.

Provide a command line tool that infers versions from your VCS. (Not completely sure if this is useful or not.)

Since there could be a bunch of artifacts here in the future, use a specific group id.

To support the new API, get a new plugin in place.

Hi,

I'm currently using the old plugin, gradle-git, but considering the switch to this one.
I am wondering if reckon can handle multi project releases from the same git repo?

Our use case is as follows:

We have some gradle modules that use GRPC and we generate code from the proto files. Let's call this project report-generator
We have the proto files in the git repository where we have the server module of our report-generator. We implement the grpc client of this report-generator service in other projects that live in other git repositories.

We use gradle git for releasing the server module of report-generator and this creates a different version of our GRPC API artifact.

We would like to be able to release our grpc module from report-generor service only when there are changes to it and not every time.

Moving this code into another git repo will make things harder to track and manage (submodules is an option but adds it's own issues).

Is there a way to have our report-generator grpc api as an independent project inside the report-generaor git repository and handle releases via separate tags?

Something like:

• v-x.y.z tag format to manage release numbering for the main project report-generator
• reports-api-a.b.c tag format to manage release numbering for report-generator grpc api

What other options do I have if that is not possible?

Thanks,

On release we publish our artifacts to Sonatype nexus and we are

Support the Scala Build Tool.

Support the Mercurial VCS.

It's clear to me, that rc or milestones are not relevant if you are on a tagged commit.
but it's even unclear to me, why then final stage should become interesting and is increased?

bash:$ git describe
0.0.1

bash:$ ./gradlew build -Preckon.scope=minor -Preckon.stage=final

> Configure project : 
Reckoned version: 0.1.0

bash:$ ./gradlew build -Preckon.scope=patch -Preckon.stage=milestone

> Configure project : 
Reckoned version: 0.0.1

bash:$ ./gradlew build -Preckon.scope=patch -Preckon.stage=rc

> Configure project : 
Reckoned version: 0.0.1

expected

bash:$ git describe
0.0.1

bash:$ ./gradlew build -Preckon.scope=minor -Preckon.stage=final

> Configure project : 
Reckoned version: 0.0.1

Support the Git VCS through grgit. A CLI-backed version could be considered in the future.

since -Preckon.stage=sdf provides a helpful hint

* What went wrong:
> Stage "sdf" is not one of: [rc, final]

-Preckon.scope=sdf only provides message

> No enum constant org.ajoberstar.reckon.core.Scope.SDF

instead of expected

> Scope "sdf" is not one of: [patch, minor, major]

Support the Maven build tool.

it's well ... undocumented ... that reckon is not working unless you add id 'org.ajoberstar.grgit' version '<version>' as in the example, else you just get No VCS found/configured. Version will be 'unspecified'..

Support the Leiningen build tool.

If no scope is provided, it should allow inference based on having a tagged pre-release.

e.g.

if base release is 1.9.3 and base version is 2.0.0-rc.1, infer scope of major, rather than using default of minor.

Hi,

Can I configure reckon to change/remove some "illegal" characters like + from the version string?

I'm using reckon to generate version and do my builds. For my project it generates version like:
2.2.0-dev.0.349+1ae1fecda2f3f9f2020c98f9d35d942a23164806 which is fine, until I try to publish a docker image with that string as tag. In that case it fails with invalid reference format.

Now, in my Jenkinsfile I can replace + with _ and publish the image but we are also using rundeck with a plugin that gets maven artifact versions from sonatype nexus.

I would like to use the same version across my artifacts so I can deploy docker images by that.

The use case is not that strong since it might have other solutions but I can't see one right now.

Support the Boot build tool.

Support the Gradle build tool.

Support the Subversion VCS.

ScopeNormalStrategy takes a Supplier<Optional<Scope>> and StagePreReleaseStrategy takes a Supplier<Optional<String>>.

These would benefit from using the context generally available to the strategies, so add new constructors:

• ScopeNormalStrategy(Function<VcsInventory, Optional<Scope>>)
• StragePreReleaseStrategy(BiFunction<VcsInventory, Version, Optional<String>>)

This would enable some things like, based on the target normal look at the corresponding GitHub milestone to tell what stage you're in.

Gradle treats 0.1.0-rc.1.dev.1 < 0.1.0-rc.1
SemVer treats 0.1.0-rc.1 < 0.1.0-rc.1.dev.1

Need to think about a way to version that satisfies both. Otherwise dynamic versions are surprising.

Hello Andrew,
I understand the plugin makes live easier by checking branches for assigned tags/versions. But what I'm trying to achieve - get the only patch component increased depending on a distance from a prev tag.
i.e git describe gives me

$ git describe
v0.1.0-3-g2acd488

and ./gradlew jar (of course)

Reckoned version: 0.1.1-SNAPSHOT

So is it possible to get somehow 0.1.3-SNAPSHOT generated? Wonder if I overlooked something in configuration.

Thanks!

gradle reckonTagPush

> Task :reckonTagCreate
Reckoned version: 0.5.0-milestone.0.5+2c00c58855390f968028a13991bf35b5a442a557

> Task :reckonTagPush
The Task.dependsOnTaskDidWork() method has been deprecated and is scheduled to be removed in Gradle 5.0. Instead, check the value of "didWork()" for each task, or declare the task inputs and outputs and let Gradle decide what needs to be run.

Gradle version

gradle --version

------------------------------------------------------------
Gradle 4.2
------------------------------------------------------------

Build time:   2017-09-20 14:48:23 UTC
Revision:     5ba503cc17748671c83ce35d7da1cffd6e24dfbd

Groovy:       2.4.11
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Mac OS X 10.12.6 x86_64

Looking at the code, I think the error is being called here.

I'm trying to workaround this issue by tagging my branches manually.
However, I think in order for the plugin to work properly, it needs to use the tasks createTag and pushTag, right?

My repository is public, I'm testing your solution for versioning artifacts using a Gradle plugin. So in order to reproduce, just clone my repository and run ./gradlew reckonTagPush.

Thank you very much for your effort in this amazing plugin! 😃

Hi there,
sorry if I ask this question, I am rather new to SemVer, so maybe Stackoverflow would be a better place to ask, but because I am evaluation this plugin, I hope you don't mind the question.

Assuming I have a current version of
0.2.0-rc.1 in branch release/0.2.0

and wile this release is prepared, which may take some time for testing etc. an other Team should work on next feature iterations but here it seems to me that this is not possible because until I have a final version(0.2.0) only the -rc.* versions are incremented and maybe I am developing new features which should result in 0.3.0-milestone even while 0.2.0-rc.* isn't released.

Or am I just totally not understanding SemVer and the whole process?

Kind regards
Mathias