Bump jackson2-api from 2.13.1-246.va8a9f3eaf46a to 2.13.1-999999-SNAPSHOT in /bom-weekly

[dependabot]

Bumps jackson2-api from 2.13.1-246.va8a9f3eaf46a to 2.13.1-999999-SNAPSHOT.

Commits

• See full diff 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)

[jglick]

@jtnord any idea what went wrong here?

[basil]

Uh, this looks like a timestamped snapshot of jenkinsci/jackson2-api-plugin#122 deployed manually by @dcendents, as evidenced by this entry in MANIFEST.MF:

Plugin-Version: 2.13.1-999999-SNAPSHOT (private-b254f61c-dbeland)

Note that this got published to the snapshots repository but not the releases repository, so this hasn't been released to users (thankfully!).

I think Daniel just didn't know that ci.jenkins.io publishes incrementals automatically, so he manually deployed a timestamped snapshot to do plugin-to-plugin testing. I've gone through and updated his PRs to use the incrementals published by ci.jenkins.io so that he doesn't need to manually publish timestamped snapshots in the future.

Why Dependabot proposed this PR is a separate question. Dependabot normally tries to filter snapshot releases in this code, but apparently this didn't work for 2.13.1-999999-SNAPSHOT.

[jglick]

And why was it even looking in the snapshots repository to begin with?

[basil]

And why was it even looking in the snapshots repository to begin with?

I think that's the expected behavior, since we have in our pom.xml files

<repositories>
    <repository>
        <id>repo.jenkins-ci.org</id>
        <url>https://repo.jenkins-ci.org/public/</url>
    </repository>
</repositories>

where I suspect the public repository is a virtual repository that delegates to both snapshots and releases?

[jglick]

Ah right. 🤔 maybe this repo should specify releases only? Might mess up anyone using exotic mirror settings, though. (Including indirectly, via something importing this BOM.) And would be inconsistent with pretty much every other repo in @jenkinsci.

[jglick]

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#registries only mentions private registries as a use case, but perhaps we could force DB config in this repo (and maybe others) to look at https://repo.jenkins-ci.org/releases/ specifically? I wonder if that overrides anything detected from the POM.

[basil]

I wonder if that overrides anything detected from the POM.

Would sure be nice if it did. Anyway, answering this question or my previous question (about why Dependabot erroneously did not mark 2.13.1-999999-SNAPSHOT as a prerelease version) likely involves debugging some Ruby code as in #794 (comment). If we don't expect people to publish timestamped snapshots in incrementalified repositories (and I don't think we do), perhaps it isn't worth spending that much time on this. I'm inclined to close this PR and defer further investigation unless some other problem comes up.

[timja]

If we don't expect people to publish timestamped snapshots in incrementalified repositories (and I don't think we do)

I occasionally publish them if:

• incrementals is broken
• ci.jenkins.io is having issues
• using a repository such as Jenkins core whose build is ridiculously long

but yeah snapshots aren't used a lot...

[jglick]

You cannot push snapshots to any but the snapshots repo.

Fine with me to just close this for now.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[jglick]

(Could also probably adjust the config file to ignore any *-SNAPSHOT version?)

[basil]

(Could also probably adjust the config file to ignore any *-SNAPSHOT version?)

Probably, though that is a workaround for the real problem, which is that Dependabot's usual logic to ignore pre-release versions isn't working with the JEP-229-ified version number being used here.

[jglick]

So another case like jenkinsci/incrementals-tools#24 perhaps.