When using -Preckon.stage=final on a clean tagged commit, the reckoned version becomes the next available version.

We’re attempting to run gradle assemble -Preckon.stage=final on tagged commits to build the version that was tagged.

reckon {
  scopeFromProp()
  snapshotFromProp()
}

When not using the final flag, the reckoned version matches the tag on the current commit.

✔ ~/PROJECT [v0.5.2|✔]
$ ./gradlew app:assemble

> Configure project :app
Reckoned version: 0.5.2

However, with the final flag, Reckon increments the version number instead.

✔ ~/Project [v0.5.2|✔]
$ ./gradlew app:assemble -Preckon.stage=final

> Configure project :app
Reckoned version: 0.5.3

The final behavior seems odd in this later case, we’d expect final build on a clean tagged commit to produce the same versioned release build as tagged.

We can resort to using the default command to build a release build matching the tag, but there’s a slight caveat here. If the repo is dirty in anyway (CI script dropping a few temp files in the source repo), then the default command will bump the version to v0.5.3-SNAPSHOT where as -Preckon.stage=final could’ve caught this and not allow a dynamic version change during automated builds.

[ajoberstar]

It appears I didn’t mention this explicitly, so to ensure people are aware… To build an existing tag without incrementing the version again, provide no input. Omit both the stage and scope and it will pick up the version already tagged. This is the exact approach used by reckon’s own release process (see the .GitHub/workflows/release.yaml) and note that I don’t provide either property to the build.

If you want added assurance that it’s a rebuild, use a task like the assert one noted above.

[bowenwp]

Thanks for the quick response.

Yes, I think that’s the correct interpretation.

To provide more context, our specific use case is building the release builds from CI hosts and to trigger the release builds off version tags. Therefore, when the builds were executed, the tag specifying the version is checked out and we want to make sure the build off that tag is always the same version. Therefore, we do want to assert it is a rebuild of the tag and not a version bump.

Is keeping the source directory clean sufficient condition to ensure the default command build the version of the tag? We would love to have final’s behavior of failing on a dirty repo as well.