Closed bric3 closed 1 year ago
I am doing something similar to that but outside of semver plugin, in Hubdle or Gradle Extensions.
There is a Gradle issue to transform version: Any
to version: Provider<Any>
, but personally I think they should avoid Any
and use a specific and deterministic type, even if it is String
.
We can add a val Project.isSnapshot: Provider<Boolean>
getter, indeed I think I should refactor the one I have to return a Provider
.
public val Project.isSnapshot: Boolean
get() = version.toString().endsWith("-SNAPSHOT", ignoreCase = true)
Change to
public val Project.isSnapshot: Provider<Boolean>
get() = provider { version.toString().endsWith("-SNAPSHOT", ignoreCase = true) }
And in semver plugin I could just expose it:
public val Project.isSnapshot: Provider<Boolean>
get() = com.javiersc.gradle.extensions.project.isSnapshot
The reason to expose a Provider
is to clearly indicate it should be consumed in tasks or lazy configurations and avoid getting its value in the configuration phase. Indeed, version.toString()
is calling get()
internally.
Additionally, we could add more for common values like isAlpha
, isBeta
, isRC
, isFinal
and so on.
Added those ones in isVersionExtension.kt:
Project.isAlpha: Provider<Boolean>
extensionProject.isNotAlpha: Provider<Boolean>
extensionProject.isBeta: Provider<Boolean>
extensionProject.isNotBeta: Provider<Boolean>
extensionProject.isDev: Provider<Boolean>
extensionProject.isNotDev: Provider<Boolean>
extensionProject.isRC: Provider<Boolean>
extensionProject.isNotRC: Provider<Boolean>
extensionProject.isSnapshot: Provider<Boolean>
extensionProject.isNotSnapshot: Provider<Boolean>
extensionAh cool !
I think the not variants like isNotSnapshot
are not needed, as prefixing with !
or using the .not
postfix in kotlin should be enough.
Also what about the API about reading the previous git tag, since it's used to compute the current version.
Maybe also reading the commit hash of the related tag. And the current commit hash as a commodity (can be used to set an entry in the manifest).
Also what about the API about reading the previous git tag, since it's used to compute the current version.
Maybe also reading the commit hash of the related tag. And the current commit hash as a commodity (can be used to set an entry in the manifest).
How would you consume those values? in a lambda in the plugin extension for example?
I'm not sure how I would consume those, I think possibly accessing those values in a custom task, or from another task.
Maybe the semver extension can have a provider with those values which can be mapped to another task input/s.
What do you think?
Maybe the semver extension can have a provider with those values which can be mapped to another task input/s.
I think that should be the right thing.
In my build script depending, I wrote some tasks that depends on the computed version, and some on the old version.
Typically choosing the repository to upload artifacts weather the version is a snapshot or a release (alpha, beta, rc, final). In another project I'm working on there's the concept of EAP (early access preview). Currently I have created my own functions that parse the version. But it would be useful if the plugin could provide those.
E.g.
Another thing that I'm currently doing differently is getting the last tag (and possibly the commit id), which could be used to trigger some tasks.