Add support for versions using git revision suffixes for Maven and Gradle by yeikel · Pull Request #13998 · dependabot/dependabot-core

yeikel · 2026-01-22T04:46:52Z

What are you trying to accomplish?

Adds support for detecting versions that include embedded Git commits in both short and long format.

The updated logic correctly parses version strings with Git revision suffixes, as used by some Maven projects (e.g., the Jenkins plugins organization). Examples: 2.9.2-29.v717aac953ff3, 2.9.3-29.v717aac953ff3

This is a follow-up for #13818 #13999

Fixes #14102

How will you know you've accomplished your goal?

Both the existing and new specs pass. I was able to reproduce the issue with the tests, and the new code resolves it

Note to reviewers

The change may look more intimidating than it actually is due to the large diff.
A bulk of the effort went into adding as many scenarios/specs as possible.
As the method grew too complex, I refactored it to prevent another RuboCop finding/muting RuboCop
A big chunk of the changes are documentation improvements

Checklist

I have run the complete test suite to ensure all tests and linters pass.
I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
I have written clear and descriptive commit messages.
I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
I have ensured that the code is well-documented and easy to understand.

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

jglick · 2026-02-05T14:29:54Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+          let(:dependency_version) { "5933.vcf06f7b_5d1a_2" }
+          let(:comparison_version) { "5857.vb_f3dd0731f44" }


Would suggest a test checking explicitly the case most recently observed to fail, that https://github.com/jenkinsci/plugin-pom/releases/tag/6.2108.v08c2b_01b_cf4d is not considered superseded by https://github.com/jenkinsci/plugin-pom/releases/tag/6.2122.v70b_7b_f659d72 which I suppose was a regression from #13818. None of the examples here seem to include a prefix prior to the revision count, as used for example in https://github.com/jenkinsci/plugin-pom/blob/623345749f5978fee57ab0e670f1f980dd5b05cd/pom.xml#L57 or even https://github.com/jenkinsci/jjwt-api-plugin/blob/b2c204d6cd36e8597dddade93d7cc95f12074943/pom.xml#L16

Thank you for the feedback @jglick. I updated the tests cases to consider that format as well as others I could find. Could you please review and let me know if I am missing any scenario?

Thanks in advance for your time and understanding

jglick · 2026-02-06T23:01:54Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+        end
+
+        context "when the version has a short git commit" do
+          let(:dependency_version) { "5622.c9c3051" }


FWIW this would never apply to Jenkins CD, which always uses a 12-digit hash after v.

Thanks, I tried to cover a mix of Jenkins use cases plus general usage for other libraries

jglick · 2026-02-06T23:02:16Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+        end
+
+        context "when the version has a single embedded git commit using different delimiters" do
+          let(:dependency_version) { "5622-c9c3051619f5" }


also never used by the Jenkins project, FWIW

Same reasoning as above, just more coverage of potential examples

jglick · 2026-02-06T23:02:58Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+          let(:dependency_version) { "5723.v6f9c6b_d1218a_" }
+          let(:comparison_version) { "5622.c9c3051619f5" }


Again, this is a downgrade…?

I am not sure what you mean with this

5723 > 5622

Sorry, what is the confusion/question here? What this test is asserting is that the two versions are "Semantically similar" to be compared. Later on during sorting is when it is decided if they are newer or not

#13998 (comment)

jglick · 2026-02-06T23:03:37Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+
+        context "when version has pre-release qualifier with git SHA" do
+          # Format: {number}.v{git-sha}-{qualifier}
+          let(:dependency_version) { "252.v356d312df76f-beta" }


never used in Jenkins FWIW

jglick · 2026-02-06T23:04:07Z

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

+        context "when one version has git SHA and other is standard semver" do
+          let(:dependency_version) { "1.2.3" }
+          let(:comparison_version) { "1.2.4.va1b2c3d" }
+
+          it { is_expected.to be false }
+        end


Why? 1.2.4 > 1.2.3

Same reason as above. Not considered semantically the same line of releases

This particular example is unlikely to ever occur in the Jenkins ecosystem but Maven does consider 1.2.4 to be newer than 1.2.3.

Just to clarify, this class/logic not about deciding if something is newer or not, it is about deciding if two versions should be "compared" to begin with

Got it, but as before, if a dep is currently written on version 1.2.3, and some 1.2.4* version is available, it should be offered.

It’s a nuanced topic.

One could argue that Dependabot should not make this decision automatically and that the choice should remain with users. That is, if something is newer and sorts within Maven, just suggest it no matter what

Others believe Dependabot should make that call (a direction I lean toward), which puts us in a somewhat uncomfortable position.

At Dependabot's current configuration capabilities it is one or the other. We cannot have both

Ideally, this behavior would be configurable to satisfy both perspectives, but we are not there yet.

Consider the following examples:

1.2.3 → 1.2.4
1.2.3 → 1.2.4-<hash>
1.2.3 → 1.2.4-<anything>-whatever-I-want
1.2.3-jdk
1.2.5-jre

Which should Dependabot offer? Whatever is newer and sorts?

Perhaps, but it’s complicated, because library authors sometimes use versioning in inconsistent or unpredictable ways. While others are more strict about their intent. The later is what I often see and what Dependabot is trying to work with

That said, I hope that the changes cover Jenkins use case. Curious to hear if I should test any other scenario.

Thanks for the feedback and I hope it makes sense. It is a great discussion!

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb

yeikel · 2026-02-11T03:54:02Z

@jglick @timja Thanks for your feedback. I believe I’ve updated the changes to cover all the scenarios you mentioned. The main update in the recent commits is that the digest is now treated as irrelevant, allowing updates to proceed even if only one artifact includes a digest.

@kbukum1 Given the impact (see #14102, affecting many repositories in the Jenkins organization), I would appreciate your review to help determine if we can move forward with releasing this change.

jglick

OK AFAICT from the test cases

kbukum1 · 2026-02-13T18:55:02Z

@jglick @timja Thanks for your feedback. I believe I’ve updated the changes to cover all the scenarios you mentioned. The main update in the recent commits is that the digest is now treated as irrelevant, allowing updates to proceed even if only one artifact includes a digest.

@kbukum1 Given the impact (see #14102, affecting many repositories in the Jenkins organization), I would appreciate your review to help determine if we can move forward with releasing this change.

Thanks @yeikel . I will check it hopefully today otherwise next week after Tuesday.

yeikel · 2026-02-20T17:45:36Z

@jglick @timja Thanks for your feedback. I believe I’ve updated the changes to cover all the scenarios you mentioned. The main update in the recent commits is that the digest is now treated as irrelevant, allowing updates to proceed even if only one artifact includes a digest.
@kbukum1 Given the impact (see #14102, affecting many repositories in the Jenkins organization), I would appreciate your review to help determine if we can move forward with releasing this change.

Thanks @yeikel . I will check it hopefully today otherwise next week after Tuesday.

Hey @kbukum1 just pinging to see if you got a chance to review this?

Thanks

kbukum1 · 2026-02-20T22:21:42Z

@jglick @timja Thanks for your feedback. I believe I’ve updated the changes to cover all the scenarios you mentioned. The main update in the recent commits is that the digest is now treated as irrelevant, allowing updates to proceed even if only one artifact includes a digest.
@kbukum1 Given the impact (see #14102, affecting many repositories in the Jenkins organization), I would appreciate your review to help determine if we can move forward with releasing this change.

Thanks @yeikel . I will check it hopefully today otherwise next week after Tuesday.

@jglick @timja Thanks for your feedback. I believe I’ve updated the changes to cover all the scenarios you mentioned. The main update in the recent commits is that the digest is now treated as irrelevant, allowing updates to proceed even if only one artifact includes a digest.
@kbukum1 Given the impact (see #14102, affecting many repositories in the Jenkins organization), I would appreciate your review to help determine if we can move forward with releasing this change.

Thanks @yeikel . I will check it hopefully today otherwise next week after Tuesday.

Hey @kbukum1 just pinging to see if you got a chance to review this?

Thanks

Hi @yeikel , sorry I have some workload and I really couldn't review that. I am hoping by mid of next week I will do review.

github-actions bot added the L: java:maven Maven packages via Maven label Jan 22, 2026

yeikel force-pushed the fix/jenkins-and-git-versions branch from e36d11b to 4433784 Compare January 22, 2026 04:48

yeikel changed the title ~~Jenkin plugin versions should be comparable~~ Add support for versions using git revision suffixes Jan 22, 2026

yeikel force-pushed the fix/jenkins-and-git-versions branch 4 times, most recently from 00bb36a to 5107728 Compare January 22, 2026 05:02

yeikel mentioned this pull request Jan 22, 2026

Version suffix should be respected #11068

Closed

1 task

yeikel changed the title ~~Add support for versions using git revision suffixes~~ Add support for versions using git revision suffixes for Maven and Gradle Jan 22, 2026

yeikel mentioned this pull request Feb 4, 2026

jenkinsci/plugin-pom updates not being offered due to incorrect Maven version logic #14102

Open

1 task

jglick reviewed Feb 5, 2026

View reviewed changes

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb Outdated Show resolved Hide resolved

jglick reviewed Feb 5, 2026

View reviewed changes

yeikel force-pushed the fix/jenkins-and-git-versions branch 18 times, most recently from 410ea63 to cab9a6a Compare February 6, 2026 03:37

jglick reviewed Feb 6, 2026

View reviewed changes

maven/spec/dependabot/maven/shared/shared_version_finder_spec.rb Outdated Show resolved Hide resolved

yeikel force-pushed the fix/jenkins-and-git-versions branch from 49ff117 to 2277801 Compare February 6, 2026 23:10

github-actions bot added the L: java:gradle Maven packages via Gradle label Feb 6, 2026

yeikel force-pushed the fix/jenkins-and-git-versions branch 2 times, most recently from 671c58b to 1b1268d Compare February 6, 2026 23:19

yeikel marked this pull request as draft February 11, 2026 01:47

yeikel force-pushed the fix/jenkins-and-git-versions branch 4 times, most recently from 4851f69 to 999a68e Compare February 11, 2026 03:50

yeikel marked this pull request as ready for review February 11, 2026 03:50

yeikel force-pushed the fix/jenkins-and-git-versions branch from 999a68e to 3080b80 Compare February 11, 2026 03:53

yeikel requested review from jglick and timja February 11, 2026 03:54

jglick reviewed Feb 11, 2026

View reviewed changes

yeikel force-pushed the fix/jenkins-and-git-versions branch 4 times, most recently from 10424f4 to f4d7925 Compare February 20, 2026 17:45

Add support for versions using git revision suffixes

d76c8b5

yeikel force-pushed the fix/jenkins-and-git-versions branch from f4d7925 to d76c8b5 Compare February 20, 2026 22:34

		let(:dependency_version) { "5933.vcf06f7b_5d1a_2" }
		let(:comparison_version) { "5857.vb_f3dd0731f44" }

		let(:dependency_version) { "5723.v6f9c6b_d1218a_" }
		let(:comparison_version) { "5622.c9c3051619f5" }

Comments

Conversation

yeikel commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What are you trying to accomplish?

How will you know you've accomplished your goal?

Note to reviewers

Checklist

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yeikel Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

yeikel commented Feb 11, 2026

Uh oh!

jglick left a comment

Choose a reason for hiding this comment

Uh oh!

kbukum1 commented Feb 13, 2026

Uh oh!

yeikel commented Feb 20, 2026

Uh oh!

kbukum1 commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

yeikel commented Jan 22, 2026 •

edited

Loading

yeikel Feb 6, 2026 •

edited

Loading