Since 18.0.5 the plugin is now completely broken - Determination of nearest tag not working any longer for semver versions

[oliverkuntze]

We have been a long time user of the nebula-release-plugin but starting with the refactoring since the 18.0.0 version the plugin is getting more and more unstable.

Things that have been working for years now aren't working any longer.
With version 18.0.5 the plugin is not able to find version tags any longer and defaults to UNKNOWN = Version.valueOf('0.0.0').

The issues section seems to be dead since no developer has reacted to any issue since June.

For the time being we pinned the plugin's version in Renovate. Quite sad, but in the mid term we seem to have to move to another plugin for semver releasing.

[pauxus]

Looking at the release notes: this should have been fixed with 7d369f6 (18.0.6)

[oliverkuntze]

Unfortunately not. The plugin still infers the incorrect release version (0.0.1) but then checks this version against the latest semantic versioning tag. One part ist fixed, the other not.
Seems as if we have to set up a migration strategy for our releasing. Really sad.
Would have loved to work with the plugin team on it but am never getting any response.

[DanielThomas]

There's been a lot of refactoring to remove the JGit dependency, configuration cache compatibility, etc. Is this still an issue with the latest release?

[DanielThomas]

I should add, there's absolutely nothing wrong with sticking with a previous major release line, if you're having trouble accomodating recent changes, and FWIW we use the plugin in hundreds of thousands of builds per month. But do check the latest release when reporting bugs.

[oliverkuntze]

Thanks for your reply, @DanielThomas !
I've tried 18.0.8 which still infers the incorrect dev version while 18.0.4 is working totally fine.
Haven't tried out 19.x since it apparently changed git auth and I have to figure out what the new way to go is.
Will give it a try.

[DanielThomas]

If the git command works correctly on the system, the plugin will too. Let us know if it's still not working with the latest release.

[oliverkuntze]

Hi @DanielThomas .
Unfortunately also 19.0.4 always infers for example 0.0.1-dev.something for the current dev version in our Gitlab CI pipeline.
Even setting the git strategy to clone and shallow clones to 0.
18.0.4 and prior versions do not behave this way.
Running the same gradle task locally on my machine yield the correct version.
Any ideas?

I can see following lines in the Gitlab Runner's logs:
2024-01-31T18:31:13.018+0000 [DEBUG] [nebula.plugin.release.git.semver.NearestVersionLocator] Nearest release: {version=0.0.0, distance=585}, nearest any: {version=1.4.78, distance=11}. 2024-01-31T18:31:13.020+0000 [DEBUG] [nebula.plugin.release.git.semver.SemVerStrategy] Located nearest version: nebula.plugin.release.git.semver.NearestVersion(1.4.78, 0.0.0, 11, 585)
1.4.78 is the correctly determinded nearest tag.
But then the log states:
2024-01-31T18:31:13.050+0000 [WARN] [nebula.plugin.release.git.semver.SemVerStrategy] Inferred project: demo, version: 0.0.1-dev.11+b5381f2

[DanielThomas]

Oh, I see the problem! We fixed a bug which caused numeric tags not prefixed with 'v' to be considered versions, and I bet you've been caught out by that. Add an adjacent tag to tag that latest release of v1.4.78 and inference should work again.

[DanielThomas]

But @rpalcolea that output still looks sus to me, do we still have a problem with tag filtering?

[oliverkuntze]

Our release tags are all prefixed with "v".
The problem seems to be somehow associated with running the release tasks from within a Gitlab CI pipeline.
I've tried git fetch strategy fetch as well as clone. Fetching all changes for all branches and tags.
I assume at Netflix you don't use Gitlab CI?
Something got broken from version 18.0.4 on.

[DanielThomas]

Ah, that's post parsing. Yeah, definitely seems odd. Let's see what Roberto says, I'm just guessing from recent commits I've seen fly by.

[oliverkuntze]

Running the gradle tasks locally produces the following log messages:
2024-02-01T08:57:42.449+0100 [DEBUG] [nebula.plugin.release.git.semver.NearestVersionLocator] Nearest release: {version=1.4.78, distance=8}, nearest any: {version=1.4.78, distance=8}. 2024-02-01T08:57:42.449+0100 [DEBUG] [nebula.plugin.release.git.semver.SemVerStrategy] Located nearest version: nebula.plugin.release.git.semver.NearestVersion(1.4.78, 1.4.78, 8, 8)
The difference regarding the logs from the Gitlab runner is that executed locally the tasks correctly determine the nearest release version.
Regarding the nearest any version local as well as Gitlab CI runs determine the correct version but the calculated distances differ.
8 is the correct distance (see attached screenshot). 11 as determined in the Gitlab CI execution is wrong.

Could it make a difference for the plugin working on a detached vs non-detached head?

[DanielThomas]

We're just using the output of git describe, we're calling:

git describe --tags --long --match v*

nebula-release-plugin/src/main/groovy/nebula/plugin/release/git/command/GitReadCommand.groovy

Lines 106 to 118 in 6eaf9a5

	abstract class DescribeHeadWithTag extends GitReadCommand {
	@Override
	String obtain() {
	try {
	return executeGitCommand( "describe", "HEAD", "--tags", "--long", "--match", "v*")
	} catch (Exception e) {
	if(e.message.contains("is externally known as") || e.message.contains('warning: tag ')) {
	return e.message.takeBetween("tag '", "'")
	}
	return null
	}
	}
	}

The documentation for describe indicates:

Annotated tags will always be preferred over lightweight tags, and tags with newer dates will always be preferred over tags with older dates.

https://git-scm.com/docs/git-describe#_search_strategy

Which is a departure from the previous JGit. Could you have a mix of lightweight and annotated commits for versions?

Unlikely to be detached commits, you get the nearest commit suffixed with the distance and abbreviated sha:

❯ git describe --tags --debug
describe HEAD
No exact match on refs or tags, searching to describe
 lightweight        5 v8.2.4
 lightweight        6 v8.2.3
 lightweight       22 v8.2.2
 lightweight       23 v8.2.1
 lightweight       47 v8.2.0
 lightweight       63 v8.1.1
 lightweight       65 v8.1.0
 lightweight       72 v8.0.3
 lightweight       74 v8.0.2
 lightweight       90 v8.0.1
traversed 94 commits
more than 10 tags found; listed 10 most recent
gave up search at 3afa77761d774a1c947c6aad56d5aca13dd63030
v8.2.4-5-g6b9f9b80

Which it looks like we're accomodating fine in

nebula-release-plugin/src/main/groovy/nebula/plugin/release/git/semver/NearestVersionLocator.groovy

Lines 91 to 102 in 6eaf9a5

	String[] parts = result.split('-')
	if(parts.size() < 3) {
	return [version: parseTag(parts[0], true), distance: 0]
	}
	String foundTag = parts.size() == 4 ? parts[0..1].join('-') : parts[0]
	String commit = gitCommandUtil.findCommitForTag(foundTag)
	List<Version> allTagsForCommit = gitCommandUtil.getTagsPointingAt(commit).collect {
	parseTag(it)
	}.findAll {
	it && excludePreReleases ? !it.preReleaseVersion : true
	}

. We build with detached HEADs here too, and do both push-to-release and tag-to-release workflows.

Check for annotated version tags, and check for git on Gitlab CI and check the debug output for the describe command to see exactly what the output is.

[oliverkuntze]

Oh damn. I think I found the cause of the problem.

The "curated" executor image provided by our infrastructure team has git 1.8 on board which does not support the exclude option with describe.
The plugin's git command finished with exit value 129 and from there on inferring the versioning information takes a wrong turn.

Locally I am using an up to date git installation. That's why everything is fine locally.

Well, I think I have to have a chat with our infrastructure team and bump git's version a bit.

Thanks for all your help and pushing me in the right direction!

I will report back once I have a current git version in usage.

[DanielThomas]

Aha! You're welcome, definitely not the easiest to track down if you don't know where to look.

Hey @rpalcolea, we might want to add a minimum version check for git, and we might not be handling an exit code correctly too.