Try using last tag when -Prelease.tryUsingLastTag=true is provided

[kranich]

Fixes #84.

Suggestions for improvements, e.g. a better name for the flag, are more than welcome.

I have introduced a new flag rather than changing the behaviour of -Prelease.useLastTag=true in order to remain backwards compatible.

The use case is as follows: Suppose that in a CI pipeline you want to use the last tag when rebuilding this tag and otherwise fallback to the default strategy to determine the project version. Then you can simply add release.tryUsingLastTag=true to the gradle.properties file of your project.

[coveralls]

Coverage decreased (-0.7%) to 58.76% when pulling 4bdb53b on kranich:try-using-last-tag into 6d7c31a on nebula-plugins:master.

[kranich]

@rpalcolea @chali Could either of you please have a look at this pull request when you find time?

[chali]

Hey @kranich, so far I'm hesitant to merge, but I'm not sure I completely understand the use case where you would like to use the feature. Could you provide an example?

[kranich]

Rather than giving an example, please let me elaborate a bit.

I am currently working in a project that has a fairly complex GitLab CI/CD pipeline where every build consists of roughly 60 jobs spread over 10 stages. About a dozen of the jobs depend on the project version determined using the nebula-release-plugin. With every push to GitLab, a development version is built. When we want to build a release or release candidate we locally run gradle candidate or gradle final which creates and pushes the appropriate tag.

The dozen jobs are identical for development and release builds except for the version strategy that is used. We cannot always use gradle -Prelease.useLastTag=true because then the build fails for development versions that do not have a version tag. On the other hand, we of course have to use the last tag when building the release.

We determine how we invoke gradle by setting an environment variable GRADLE to gradle -Prelease.useLastTag=true or gradle in a before_script section of the .gitlab-ci.yml depending on whether ${CI_COMMIT_TAG} is defined or not. Then in every job, we use ${GRADLE} instead of simply gradle to run the gradle tasks.

Firstly, the before_script workaround is not nice insofar as it is also run before non-gradle jobs that do not actually need it. Secondly, it is also error-prone, since developers may (and actually did) forget to always use ${GRADLE} instead of gradle.

If this PR was merged, we could put release.tryUsingLastTag=true into gradle.properties, remove the before_script section and use gradle everywhere.

Presumably @asoee had a similar use case in mind when filing issue #84.

[chali]

@kranich I understand the use case now. Unfortunately, we won't be able to merge the feature. It is very specific to your situation. The core idea of the plugin is to have a clear action leading to a clear output eg: calling ./gradlew final -> publishing final release. With this flag, it would be context-dependent what is the output. You can see in our pipelines we always make the decision explicitly based on the situation. https://github.com/nebula-plugins/nebula-release-plugin/blob/master/gradle/buildViaTravis.sh If a build is triggered by a tag we use the --release.useLastTag to read what was the selected version and build a release. Otherwise, we use just ./gradlew clean build. In our experience, this is better understood by users.

I believe nebula.release plugin allows you to build on top of it and capture the opinion you would like to have. Your users then would consume your wrapper plugin.

[kranich]

OK. Thank you for the review and the suggestion of building a wrapper plugin.

Maybe then you should close #84 as well.