Closed TomasHofman closed 5 years ago
Technically we don't need to work with sorted tags at all, the line we are calling in our build is:
tasks {
"jar"(Jar::class) {
this.manifest {
attributes["Scm-Revision"]=versioning.info.commit // <=
...
}
}
}
but even that triggers the sorting.
Also, what I should have written first of all, thank you for a useful plugin ;-).
Hi @TomasHofman ,
Thanks for reporting this.
Can I ask why you need this plugin in the first place if you only need the commit? If you need only the current commit, I guess you could use a simpler plugin like https://github.com/ajoberstar/gradle-git ?
The versioning
plugin allows to manage your versions beyond the commit ID aspect.
Do I make sense? Or is there something I don't see?
Thanks, Damien
Hello Damien,
yes, absolutely makes sense.
I asked around and nobody is really sure if we had any plans to use the plugin for anything beyond commit id. So it looks it looks the simplest thing is that we just use a different way of getting commit id.
Sorry for the noise and thank you for suggestions! ;-)
We have tooling that creates tags with commit ids in the name, e.g.:
This breaks the versioning plugin.
The versioning plugin tries to extract a numeric trailing portion of the tag name and sort tags according to these numbers (there is also another round of sorting based on commit time). In this case the number it extracts is "38328973134", which is then cast to
int
which fails with NumberFormatException, because the number is too large for theint
type.Obviously this sorting logic doesn't fit our case, but that itself is not a problem for us. The problem is that the build fails.
Would it be possible to avoid the NFE in some way? E.g. by providing a way to disable this part of the sorting mechanism. Looking at the code it looks it cannot be avoided: