Create an initial documentation page for Dependabot #40
Conversation
| Jenkins project repositories currently use the Github-native Dependabot and the deprecated standalone versions, | ||
| migration is pending. | ||
|
|
||
| This page documents jenkins-specific recommendations for using Dependabot in the Jenkins repositories. |
There was a problem hiding this comment.
| This page documents jenkins-specific recommendations for using Dependabot in the Jenkins repositories. | |
| This page documents Jenkins-specific recommendations for using Dependabot in the Jenkins repositories. |
| Jenkins project repositories currently use the Github-native Dependabot and the deprecated standalone versions, | ||
| migration is pending. |
There was a problem hiding this comment.
| Jenkins project repositories currently use the Github-native Dependabot and the deprecated standalone versions, | |
| migration is pending. | |
| Jenkins project repositories currently use the Github-native Dependabot and the deprecated standalone versions (migration is pending). |
|
|
||
| * Make sure that you do not disable Maven Enforcer Plugin when using Dependabot. | ||
| Otherwise there will be a high risk of unnoticed dependency and binary compatibility conflicts. | ||
| * It is **not recommended** to automatically update Jenkins core to the most recent versions, because it will prevent LTS users from using them. |
There was a problem hiding this comment.
Huh?
First of all, it would be fine to enable Dependabot on Jenkins core, so long as you picked an appropriate pattern: *.*.* or whatever the syntax is. (And even if you left the version to float freely to weeklies, this would not prevent LTS users from running your plugin—only the latest versions of your plugin, released after the last LTS branching point.)
But anyway, as far as I know it does not work; Dependabot does not grok that
<jenkins.version>2.176.3</jenkins.version>is fixing the version of an artifact defined in a parent POM and is thus eligible for upgrade. It only looks for artifacts defined in the literal pom.xml as far as I understand it.
You say you can configure a filter to prevent Dependabot from upgrading Jenkins core, but the plugin example does not do so.
There was a problem hiding this comment.
Makes sense. I'd rather keep the config file smaller if this is something Dependabot does not do (anymore) I think.
There was a problem hiding this comment.
BTW, the example to simply ignore Jenkins Core updates would be https://github.com/jenkinsci/configuration-as-code-plugin/blob/0aff116d84574d8880530176269edaef6bc8b023/.github/dependabot.yml#L8-L11.
| * It is **not recommended** to automatically update Jenkins core to the most recent versions, because it will prevent LTS users from using them. | ||
| See https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/[this page] for baseline selection recommendations. | ||
| You can configure a filter to prevent Dependabot from updating Jenkins core versions (see the examples) | ||
| * There is a https://github.com/jenkinsci/bom/[Plugin Bill of Materials] which defines versions for many most used plugins. |
There was a problem hiding this comment.
| * There is a https://github.com/jenkinsci/bom/[Plugin Bill of Materials] which defines versions for many most used plugins. | |
| * There is a https://github.com/jenkinsci/bom/[Plugin Bill of Materials] which defines versions for many plugins in common use as dependencies. |
| * Be careful with library dependencies, especially for popular utility libraries. | ||
| Requiring recent versions may sometimes cause binary conflicts with other plugins and the core. |
There was a problem hiding this comment.
This is threatening yet so vague as to be useless. If you are going to say anything, at least link to https://www.jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/#bundling-third-party-libraries
And the example link is to an obscure plugin that
- Includes library dependencies like
asmfew plugins would use. - Is blocking updates to the
jackson2-apiplugin, as well as other plugins defined in thebom.
Better pick a different example.
| NOTE: More examples will be added when project migrate to a GitHub-native Dependabot implementation with a v2 configuration format | ||
| (`.github/dependabot.yml` files and configurations in GitHub project settings). |
There was a problem hiding this comment.
I think it is worth holding off on docs until we have better, more typical examples.
The canonical example is far simpler: https://github.com/jenkinsci/archetypes/blob/3e5a8cc4f208c51203cac20b882ccfcba397c657/common-files/.github/dependabot.yml
There was a problem hiding this comment.
This PR will help many people to be up to date wrt dependencies. I would suggest to add two basic examples that may work for everyone as first step. A simple configuration:
/.github/dependabot.yml:
version: 2
updates:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "weekly"
And the same for just take into account security updated. Although I don't know exactly if it works for maven projects. I've read it only works on other dependencies managers: https://dependabot.com/blog/security-updates-only/ It's a 2-years-old blog entry, but the java-maven integration is still marked as Beta. 🤷
GitHub automatically files Dependabot PRs for dependencies with published CVEs, whether you configure Dependabot or not. |
Creates a minimum page with recommendations for Java/Maven plugins stack