Bump resource-disposer from 0.16 to 0.17 in /bom-weekly

[dependabot]

Bumps resource-disposer from 0.16 to 0.17.

Release notes

Sourced from resource-disposer's releases.

0.17

📦 Dependency updates

• Bump plugin parent POM from 4.19 to 4.32 (#43, #42, #40, #39, #38, #35, #33, #32, #31) @​dependabot
• Bump plugin BOM from 867.v1fa45e78abe9 to 887.vae9c8ac09ff7 (#29) @​dependabot

👻 Maintenance

• Bump baseline to 2.235 (#41) @​basil

🚦 Tests

• Remove PowerMock (#37) @​offa
• Test with latest LTS (#34) @​basil

Commits

• c0996bc [maven-release-plugin] prepare release resource-disposer-0.17
• 1e61121 Bump plugin from 4.31 to 4.32
• b4b87f2 Bump plugin from 4.29 to 4.31
• 8808143 Fix deprecation warnings
• 8958286 Bump baseline to 2.235 (#41)
• 59c5762 useAci => useContainerAgent
• da18485 Update Dependabot configuration
• 2c34ec8 Merge pull request #40 from jenkinsci/dependabot/maven/org.jenkins-ci.plugins...
• 9e07f11 Bump plugin from 4.28 to 4.29
• ac7c4e9 Merge pull request #39 from jenkinsci/dependabot/maven/org.jenkins-ci.plugins...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[basil]

I love plugins that have not adopted the unusual release versioning scheme introduced in JEP-229. Dependabot has no problem updating those.

[jetersen]

@basil well once updated it seems to work just fine: #767

[basil]

well once updated it seems to work just fine

… at least some of the time. Not so in the case of jenkinsci/jenkins#6054.

If there is an instance where Dependabot failed to propose an update to a plugin or component using a traditional (non JEP-229) versioning schema, I am not aware of it.

[jetersen]

@basil okay indicates an issue with the indexer on artifactory for repo.jenkins-ci.org or that antifactory is serving something from a cached version.

[basil]

indicates an issue with the indexer on artifactory for repo.jenkins-ci.org or that antifactory is serving something from a cached version

I fail to see any evidence in support of this claim. In contrast, I do see evidence in support of my claim that this has something to do with JEP-229:

If there is an instance where Dependabot failed to propose an update to a plugin or component using a traditional (non JEP-229) versioning schema, I am not aware of it.

[jetersen]

Dependabot relies on maven-metadata.xml and it is very easy to grab the latest version from it:

Had plenty of experience with artifactory not being reliably inside the indexed maven-metadata.xml to my claim is from experience with Artifactory in over 4 years on premise.

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>org.jenkins-ci.main</groupId>
  <artifactId>jenkins-test-harness</artifactId>
  <versioning>
    <latest>1674.v3b8b1441e939</latest>
    <release>1674.v3b8b1441e939</release>
    <versions>
        ...
    </versions

[basil]

my claim is from experience with Artifactory in over 4 years on premise.

Your previous experiences do not necessarily reflect what is happening in this particular instance.

Dependabot relies on maven-metadata.xml

In the case of structs, https://repo.jenkins-ci.org:443/public/org/jenkins-ci/plugins/structs/maven-metadata.xml has latest and release set to 308.v852b473a2b8c and was last updated 2021-11-29. Yet the Dependabot log you posted from 2021-12-25, which fetched that same URL with HTTP response 200, stated incorrectly "Latest version is 1.24". I see no evidence that Artifactory is to blame in this case.

[jetersen]

At least when Jenkins CI is restoring maven dependencies it has multiple times been detected that the HTTP content does not match the expected size which turns the builds red.
I am not sure whether Ruby or dependabot checks for this failure.

[basil]

I debugged this. As I suspected, @jetersen was incorrect in his theory that this has something to do with Artifactory. As I suspected, this has everything to do with JEP-229.

The code in

https://github.com/dependabot/dependabot-core/blob/f146743aa400c7913b5e953e1b93c8b40345aaf4/maven/lib/dependabot/maven/update_checker/version_finder.rb#L33

is filtering out some (but not all) JEP-229 versions as prereleases. Which ones? The ones matching these criteria

https://github.com/dependabot/dependabot-core/blob/f146743aa400c7913b5e953e1b93c8b40345aaf4/maven/lib/dependabot/maven/version.rb#L50-L57

based on a tokenization of runs of successive digits or letters.

Note that "a and "b" are among the list. So if a JEP-229 version contains a commit whose hash happens to contain a digit, the letter "a" or "b" and another digit, Dependabot will consider the version a prerelease and disqualify it as a potential update.

[basil]

So if a JEP-229 version contains a commit whose hash happens to contain a digit, the letter "a" or "b" and another digit, Dependabot will consider the version a prerelease and disqualify it as a potential update.

Dependabot's tokenization matches Maven's:

$ java -jar /home/basil/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 308.v852b473a2b8c     
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 308.v852b473a2b8c -> 308.v-852-beta-473-alpha-2-beta-8-c; tokens: [308, v, [852, [beta, [473, [alpha, [2, [beta, [8, [c]]]]]]]]]
$ java -jar /home/basil/.m2/repository/org/apache/maven/maven-artifact/3.8.4/maven-artifact-3.8.4.jar 1107.v5dab75aaccbd
Display parameters as parsed by Maven (in canonical form and as a list of tokens) and comparison result:
1. 1107.v5dab75aaccbd -> 1107.v-5-dab-75-aaccbd; tokens: [1107, v, [5, [dab, [75, [aaccbd]]]]]

The canonical form of the JEP-229 release version 308.v852b473a2b8c is 308.v-852-beta-473-alpha-2-beta-8-c, which is a Maven prerelease. The canonical form of the JEP-229 version 1107.v5dab75aaccbd is 1107.v-5-dab-75-aaccbd, which is not a Maven prerelease. The design of JEP-229 release versions did not take into account Maven prereleases. Dependabot does, and it doesn't offer them.

[jetersen]

Thanks @basil for checking out dependabot sources and verifying this. Great findings!
Perhaps this could be an suggestion that logging for dependabot should be improved so that it logs what it filters out and why.

@jglick perhaps something should be reconsidered? Based on @basil findings.

I was not excluding that it could be dependabot. But I have had issues previously with indexer on antifactory not serving the correct versions. Perhaps this is not an issue anymore, been a while since I used antifactory.

[timja]

Nice digging!

I've created jenkins-infra/jenkins.io#4783