Proposal: Automating dependency management for repositories inside the jenkinsci org

890 views
Skip to first unread message

Oleg Nenashev

unread,
Feb 21, 2019, 8:43:48 AM2/21/19
to JenkinsCI Developers
Dear all,

I would like to follow-up on the Dependabot request from Jesse Glick in INFRA-1975. Dependabot is a service for automated dependency updates which supports many languages/tools, including Maven, Docker and Gradle which are being heavily used in Jenkins.

Dependency management is a problem in Jenkins, because we have hundreds of repositories with many dependencies there. Maintainers spend a lot of time on managing dependencies, and sometimes it leads to ancient dependencies in components. Especially in the development tools which "just work". By automating dependency updates we could give maintainers more time to focus on other tasks.

Dependabot is one of the engines we could use for dependency management. It is free for open-source projects, and it is a SaaS application which can be almost completely managed from GitHub. It can just create pull requests or, if we want, implement validated merge with help of ci.jenkins.io. No special infrastructure required, and this is an advantage for us. There are other implementations (including UpdateBot by Fabric8/Jenkins X which has a Jenkins plugin), but it would require more efforts to deploy the infrastructure. It could be considered in the future if we want to have Jenkins-powered update management in the final implementation.

My proposal would be to enable Dependabot for a limited number of Jenkins repositories so that we can experiment with it. I propose to focus on development tools and pre-1.0 projects only for now so that we can experiment with flow without a risk of impact on components being used in production in the Jenkins project. And we will be setting up auto-updates only for projects with existing test automation.
More repositories can be added if somebody is interested to participate in the Dependabot evaluation. If there is a positive feedback after the initial evaluation, we could proceed with creating a JEP to define the flow and the usage/administration policies.

What do you think?

Thanks in advance,
Oleg

Jesse Glick

unread,
Feb 21, 2019, 9:40:41 AM2/21/19
to Jenkins Dev
On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> I propose to focus on development tools

Since the primary use case is offering updates to plugin repositories,
I would suggest including at least one example of `*-plugin`.

The question is which dependencies ought to be eligible for upgrade. I
do not think we want to update Jenkins core or plugin dependencies
gratuitously, since this would limit availability of new releases with
only modest productivity gain: more realistic functional tests, less
distance from `master` to whatever `plugin-compat-tester` would use.

Definitely we can freely upgrade the parent POM. I would be happy for
such updates to be auto-merged in fact, so long as the build passes
obviously.

> pre-1.0 projects only

Or just plugins that (a) have fairly low installation count, (b) are
maintained by people actively participating in the trial.

> More repositories can be added if somebody is interested to participate in the Dependabot evaluation.

Sign me up!

I _do_ need to make sure I get notifications of these PRs in
Octobox.io, if they are not simply automerged. Merely watching a
repository is not enough—GH has autosubscribed me to hundreds of
repos, and the resulting thousands of notifications go to /dev/null.
Maybe Dependabot can be configured to request me as a reviewer?

Mark Waite

unread,
Feb 21, 2019, 10:28:41 AM2/21/19
to jenkinsci-dev


On Thu, Feb 21, 2019 at 6:43 AM Oleg Nenashev wrote:
Dear all,

My proposal would be to enable Dependabot for a limited number of Jenkins repositories so that we can experiment with it. I propose to focus on development tools and pre-1.0 projects only for now so that we can experiment with flow without a risk of impact on components being used in production in the Jenkins project. And we will be setting up auto-updates only for projects with existing test automation.
More repositories can be added if somebody is interested to participate in the Dependabot evaluation. If there is a positive feedback after the initial evaluation, we could proceed with creating a JEP to define the flow and the usage/administration policies.


I added it to my forked repositories of the git plugin, git client plugin, and platform labeler plugin.  The experiment has been educational.  I like seeing the pull requests which are proposed.  Updates to the parent pom could be automerged if CI jobs pass.  I believe that updates to test dependencies could be automerged if CI jobs pass.
Updates to non-test dependencies are not very helpful for me.  When dependabot suggests that the git plugin should rely on the latest release of some other plugin, it risks placing unnecessary demands on users to install newer plugins than are required.  I tell dependabot to stop offering those dependency updates.  It closes the pull requests and stops offering updates to that component.
 
Mark Waite

R. Tyler Croy

unread,
Feb 21, 2019, 11:10:58 AM2/21/19
to jenkin...@googlegroups.com

I'm game for experimenting with this :D

On Thu, 21 Feb 2019, Oleg Nenashev wrote:

> Dear all,
>
> I would like to follow-up on the Dependabot request from Jesse Glick in
> INFRA-1975 <https://issues.jenkins-ci.org/browse/INFRA-1975>. Dependabot
> <https://dependabot.com/> is a service for automated dependency updates
> which supports many languages/tools, including Maven, Docker and Gradle
> which are being heavily used in Jenkins.
>
> Dependency management is a problem in Jenkins, because we have hundreds of
> repositories with many dependencies there. Maintainers spend a lot of time
> on managing dependencies, and sometimes it leads to ancient dependencies in
> components. Especially in the development tools which "just work". By
> automating dependency updates we could give maintainers more time to focus
> on other tasks.
>
> Dependabot is one of the engines we could use for dependency management. It
> is free for open-source projects, and it is a SaaS application which can be
> almost completely managed from GitHub. It can just create pull requests or,
> if we want, implement validated merge with help of ci.jenkins.io. No
> special infrastructure required, and this is an advantage for us. There are
> other implementations (including UpdateBot
> <https://github.com/jenkins-x/updatebot> by Fabric8/Jenkins X which has a
> Jenkins plugin), but it would require more efforts to deploy the
> infrastructure. It could be considered in the future if we want to have
> Jenkins-powered update management in the final implementation.
>
> My proposal would be to enable Dependabot for a *limited number* of Jenkins
> repositories so that we can experiment with it. I propose to focus on
> development tools and pre-1.0 projects only for now so that we can
> experiment with flow without a risk of impact on components being used in
> production in the Jenkins project. And we will be setting up auto-updates
> only for projects with existing test automation.
>
> - Jenkinsfile Runner - Example PRs in my local repo
> <https://github.com/oleg-nenashev/jenkinsfile-runner/pulls>
> - ci.jenkins.io-runner - Example PRs
> <https://github.com/jenkinsci/ci.jenkins.io-runner/pulls> (bot was
> disabled after moving the repo)
> - plugin-pom - Example PRs in my local repo
> <https://github.com/oleg-nenashev/plugin-pom/pulls>
> - maven-hpi-plugin - Example PRs in my local Repo
> <https://github.com/oleg-nenashev/maven-hpi-plugin/pulls>
>
> More repositories can be added if somebody is interested to participate in
> the Dependabot evaluation. If there is a positive feedback after the
> initial evaluation, we could proceed with creating a JEP to define the flow
> and the usage/administration policies.
>
> What do you think?
>
> Thanks in advance,
> Oleg
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLA1W66hN6PmaQaBUai2MJSo1nnWJA1y59tcJQskEPrMvA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
GitHub: https://github.com/rtyler

GPG Key ID: 0F2298A980EE31ACCA0A7825E5C92681BEF6CEA2

Gavin Mogan

unread,
Feb 21, 2019, 11:21:36 AM2/21/19
to jenkin...@googlegroups.com
Another one to look at is Renovate bot ( https://renovatebot.com/docs/ )

I suspect maven doesn't update nearly as often as node does, but i have greenkeeper on a lot of my node projects, and sometimes when something updates (like the testing framework) i get a huge number of PRs really quickly.

Renovate bot does have support for auto merging PRs if you want, so it can handle things a little automated.

But I'm +1 for Dependabot

Oleg Nenashev

unread,
Feb 21, 2019, 6:25:06 PM2/21/19
to Jenkins Developers
Hi all,

Thanks for the responses! If there is no negative feedback, I will proceed with the implementation next Monday. Whomever wants to add any extra components to evaluation, please comment in this thread.

Jesse: Since the primary use case is offering updates to plugin repositories,
I would suggest including at least one example of `*-plugin`. ..... if (a) have fairly low installation count (b) are maintained by people actively participating in the trial. 

maven-hpi-plugin matches the wildcard :P
Speaking seriously, we could try to add some Jenkins plugins to the experiment if (a) and (b) conditions are met.
If Mark wants to try out his plugins

Mark: Updates to non-test dependencies are not very helpful for me.  When dependabot suggests that the git plugin should rely on the latest release of some other plugin, it risks placing unnecessary demands on users to install newer plugins than are required.  I tell dependabot to stop offering those dependency updates.  It closes the pull requests and stops offering updates to that component.

Yes, dependabot can be controlled by GitHubCommentOps or Configuration-as-Code. It may require maintainers to set up filters, but then it will work like a charm. For evaluation purposes I would recommend configuration-as-code tho. It may help us to easily verify the configured filters later.

Jesse: The question is which dependencies ought to be eligible for upgrade. I do not think we want to update Jenkins core or plugin dependencies gratuitously, since this would limit availability of new releases with only modest productivity gain: more realistic functional tests, less distance from `master` to whatever `plugin-compat-tester` would use.

 Same as above, we could somehow configure it via filters somehow though it might be not trivial. I think that we will need to...
  1. Document recommendations in JEP after the evaluation
  2. Provide Config File samples (in JEP) so that maintainers can configure Dependabot correctly
Maybe Dependabot can be configured to request me as a reviewer? 

Yes, it can.

Best regards,
Oleg

Mark Waite

unread,
Feb 21, 2019, 6:51:09 PM2/21/19
to jenkinsci-dev
On Thu, Feb 21, 2019 at 4:25 PM Oleg Nenashev  wrote:
Hi all,

Thanks for the responses! If there is no negative feedback, I will proceed with the implementation next Monday. Whomever wants to add any extra components to evaluation, please comment in this thread.

Jesse: Since the primary use case is offering updates to plugin repositories,
I would suggest including at least one example of `*-plugin`. ..... if (a) have fairly low installation count (b) are maintained by people actively participating in the trial. 

maven-hpi-plugin matches the wildcard :P
Speaking seriously, we could try to add some Jenkins plugins to the experiment if (a) and (b) conditions are met.
If Mark wants to try out his plugins


The platformlabeler plugin meets conditions (a) and (b).  The other two plugins I maintain don't meet condition (a).   Definitely enable it on platformlabeler-plugin.

I'm willing to try it on the other two plugins I maintain, but am also fine skipping them if it is not comfortable for the community.

I will actively participate in the trial.
 
Mark: Updates to non-test dependencies are not very helpful for me.  When dependabot suggests that the git plugin should rely on the latest release of some other plugin, it risks placing unnecessary demands on users to install newer plugins than are required.  I tell dependabot to stop offering those dependency updates.  It closes the pull requests and stops offering updates to that component.

Yes, dependabot can be controlled by GitHubCommentOps or Configuration-as-Code. It may require maintainers to set up filters, but then it will work like a charm. For evaluation purposes I would recommend configuration-as-code tho. It may help us to easily verify the configured filters later.


That looks great.  I'm happy to try the configuration as code route.

Mark Waite

Jesse Glick

unread,
Feb 22, 2019, 8:31:02 AM2/22/19
to Jenkins Dev
On Thu, Feb 21, 2019 at 6:25 PM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Speaking seriously, we could try to add some Jenkins plugins to the experiment if (a) and (b) conditions are met.

To start with, sign me up for:

* log-cli
* pipeline-cloudwatch-logs
* parallel-test-executor
* mock-slave

which should give a decent mix.

> I would recommend configuration-as-code

Yes please.

> Document recommendations in JEP after the evaluation
> Provide Config File samples (in JEP) so that maintainers can configure Dependabot correctly

Definitely.

Ullrich Hafner

unread,
Feb 22, 2019, 10:53:03 AM2/22/19
to Jenkins Developers
I like this idea as well. You can enable it for

- analysis-model
- warnings-ng-plugin
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0dYNeFLmspUCp_DzZMSdED4fERkQQSUYEEs2tsud6xjA%40mail.gmail.com.
signature.asc

Joseph P

unread,
Feb 22, 2019, 5:55:23 PM2/22/19
to Jenkins Developers
Please enable it for

* bitbucket-branch-source-plugin
* mstest-plugin
* vstestrunner-plugin

Oleg Nenashev

unread,
Feb 25, 2019, 8:35:45 AM2/25/19
to Jenkins Developers
Hi all,

I have enabled Dependabot and added the requested components. Enjoy the PR notifications in your Inbox :) 

I have also started a Google Doc where everybody is welcome to put comments/feedback about the evaluation. It should help us to discuss the experienced issues and to create best practices/policies in the future JEPs.
 
Hi Ulli and Joseph,

As discussed above, there is a preference to limit the testing scope to development tools and to plugins with low usage numbers for now. I have added "analysis-model" and "vstestrunner" components for now, but I would prefer to wait a bit before we add other plugins.

BR, Oleg

Baptiste Mathus

unread,
Feb 27, 2019, 8:04:43 AM2/27/19
to Jenkins Developers
Thanks for driving this Oleg!

I'm in for the plugins I'm maintaining:

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Oleg Nenashev

unread,
Mar 4, 2019, 9:40:57 AM3/4/19
to Jenkins Developers
Hi Baptiste, the requested repositories have been added.

@All I also added the Plugin Compat Tester and Custom WAR Packager repositories

Both of them are development tools, so it should be ok.

Best regards,
Oleg

Raphael Pionke

unread,
Mar 11, 2019, 5:54:57 AM3/11/19
to Jenkins Developers
Hi Oleg,

i'm also interested! can you please add following repo?
Raphael

Oleg Nenashev

unread,
Mar 18, 2019, 6:05:08 AM3/18/19
to Jenkins Developers
Hi Raphael,

Done.

BR, Oleg

Jesse Glick

unread,
Mar 27, 2019, 12:26:13 PM3/27/19
to Jenkins Dev
Please remove `pipeline-cloudwatch-logs-plugin` since its interesting
tests are not currently run in CI.

Carlos Sanchez

unread,
May 2, 2019, 3:28:33 AM5/2/19
to Jenkins Developers

On Wed, Mar 27, 2019 at 5:33 PM Jesse Glick <jgl...@cloudbees.com> wrote:
Please remove `pipeline-cloudwatch-logs-plugin` since its interesting
tests are not currently run in CI.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Baptiste Mathus

unread,
May 2, 2019, 3:35:19 AM5/2/19
to Jenkins Developers

Matt Sicker

unread,
May 21, 2019, 2:36:45 PM5/21/19
to jenkin...@googlegroups.com

Mark Waite

unread,
May 21, 2019, 3:12:19 PM5/21/19
to jenkinsci-dev
I've been very happy with dependabot enabled on the platformlabeler-plugin in the Jenkins organization.  

I've also continued my experiment allowing it to run on my forks of the git plugin and git client plugin.  It has been helpful in all cases.

By the time I am reviewing a dependabot pull request to update a dependency, the CI job has completed and test results are available.


For more options, visit https://groups.google.com/d/optout.


--
Thanks!
Mark Waite

Matt Sicker

unread,
May 21, 2019, 3:36:02 PM5/21/19
to jenkin...@googlegroups.com
I'd really love to see the jackson repo most of all because I could
get the PR ready to release by the time jackson gets around to
announcing that release. Helps speed up resolution of their countless
CVEs over time.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFLGQ%3DkRezSywLV9xQubrG6bxxmeMAahoZ%2BXcNyzEh0kA%40mail.gmail.com.

Gavin Mogan

unread,
May 22, 2019, 8:56:21 PM5/22/19
to jenkin...@googlegroups.com
Can blueocean-display-url-plugin get it enabled? is it setup for all deps or only the parent plugin?
Can blueocean-plugin get updated for the parent plugin (or is that a config file somewhere)?

Oleg Nenashev

unread,
May 23, 2019, 2:47:09 AM5/23/19
to Jenkins Developers
Hi all,

I am fine with going forward with enabling Dependabot for a wider set of plugins. But IMHO it is still not ready for GA. Why?
  • We are still missing usage guidelines as it was discussed in the original emails
  • In Dependabot there is also no way to set Dependabot on an organization level, and it complicates the adoptions for plugins (dependabot/feedback/issues/353)
  • Dependabot needs write permissions to the repo. If you want to enable it for a mission-critical component, it might make sense to think twice before doing so
  • We are missing feedback from early adopters. There are some comments in this thread + this Google Doc.
Personally I am pretty fine with Dependabot results for my projects, and I am ready to go forward with plugins.


I'd really love to see the jackson repo most of all because I could get the PR ready to release by the time jackson gets around to  announcing that release. Helps speed up resolution of their countless CVEs over time. 
- show quoted text -

With Dependabot you get "eventual security" (c) at best. Delivery of patches may be delivered by a week or so. It does not replace the security process in the Jenkins organization, but I do agree that keeping dependencies up to date reduced number of issues in projects which disclose security fixes post-factum after the release.

is it setup for all deps or only the parent plugin?
Can blueocean-plugin get updated for the parent plugin (or is that a config file somewhere)?
  • Dependabot manages all dependencies it can digest. It can handle almost all dependencies in Maven, including ones with versions defined by system properties. Maven plugins will be also updated
  • BlueOcean plugins (multi-module repos) will be also handled by Dependabot. Now it supports multi-module repos 
Can I have the following added: 
 Can blueocean-display-url-plugin get it enabled?

 I can add them if you want to proceed after the comments above.

Best regards,
Oleg


On Thursday, May 23, 2019 at 2:56:21 AM UTC+2, Gavin Mogan wrote:
Can blueocean-display-url-plugin get it enabled? is it setup for all deps or only the parent plugin?
Can blueocean-plugin get updated for the parent plugin (or is that a config file somewhere)?

On Tue, May 21, 2019 at 12:36 PM Matt Sicker <msi...@cloudbees.com> wrote:
I'd really love to see the jackson repo most of all because I could
get the PR ready to release by the time jackson gets around to
announcing that release. Helps speed up resolution of their countless
CVEs over time.

On Tue, May 21, 2019 at 2:12 PM Mark Waite <mark.e...@gmail.com> wrote:
>
> I've been very happy with dependabot enabled on the platformlabeler-plugin in the Jenkins organization.
>
> I've also continued my experiment allowing it to run on my forks of the git plugin and git client plugin.  It has been helpful in all cases.
>
> By the time I am reviewing a dependabot pull request to update a dependency, the CI job has completed and test results are available.
>
> On Tue, May 21, 2019 at 12:36 PM Matt Sicker <msi...@cloudbees.com> wrote:
>>
>> Can I have the following added:
>>
>> https://github.com/jenkinsci/jackson2-api-plugin
>> https://github.com/jenkinsci/jsch-plugin
>> https://github.com/jenkinsci/pam-auth-plugin
>> https://github.com/jenkinsci/ssh-credentials-plugin
>> https://github.com/jenkinsci/audit-log-plugin
>>
>> On Thu, May 2, 2019 at 2:35 AM Baptiste Mathus <m...@batmat.net> wrote:
>> >
>> > Done Carlos.
>> >
>> > Le jeu. 2 mai 2019 à 09:28, Carlos Sanchez <car...@apache.org> a écrit :
>> >>
>> >> please add https://github.com/jenkinsci/kubernetes-plugin
>> >>
>> >> thanks
>> >>
>> >> On Wed, Mar 27, 2019 at 5:33 PM Jesse Glick <jgl...@cloudbees.com> wrote:
>> >>>
>> >>> Please remove `pipeline-cloudwatch-logs-plugin` since its interesting
>> >>> tests are not currently run in CI.
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> >>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

>> >>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3%2BA%3DuSo4kmOM_BXjbOVeN9u9UFUChB59csZGhW7AoPgA%40mail.gmail.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

>> >> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALHFn6OAy5HHW_aDNp-xCv69zxvW7p05VCdXh9LjVte%3DOpRhjA%40mail.gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

>> > To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7fQSpnUf8GhGdFyXcQ6SErLMbM9F0PuUKgyAVLzPdi4A%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Matt Sicker
>> Senior Software Engineer, CloudBees
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

>> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAEot4oxJn9wy4t%2BQpH7y2ExWtC4tBEUWSawrQmCy1ucJAx77XQ%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFLGQ%3DkRezSywLV9xQubrG6bxxmeMAahoZ%2BXcNyzEh0kA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



--
Matt Sicker
Senior Software Engineer, CloudBees

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.

Gavin Mogan

unread,
May 23, 2019, 2:59:10 AM5/23/19
to jenkin...@googlegroups.com
Please go ahead with both, I can always @dependbot ignore on blueocean as needed.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/39d5d27a-4371-4bf5-b8fb-89e1b77419ef%40googlegroups.com.

Matt Sicker

unread,
May 23, 2019, 11:04:16 AM5/23/19
to jenkin...@googlegroups.com
If dependabot is somehow slower than I am at updating dependencies,
I'll make sure to complain to them. ;)
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAAgr96%2BuzzLs5r4Atc6vJNVxGq_h3Do-KyCq11GYpG1TFH8XKA%40mail.gmail.com.

Basil Crow

unread,
Jun 10, 2019, 12:40:38 PM6/10/19
to Jenkins Developers
On Wednesday, May 22, 2019 at 11:47:09 PM UTC-7, Oleg Nenashev wrote:
I am fine with going forward with enabling Dependabot for a wider set of plugins.

 Can you please add the following repositories:


Thanks,
Basil

Oleg Nenashev

unread,
Jun 10, 2019, 1:04:08 PM6/10/19
to JenkinsCI Developers
done!

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/XMllKuWLO_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e15d83eb-6fe5-4c80-99a5-d124fbd19134%40googlegroups.com.

Oleg Nenashev

unread,
Jul 23, 2019, 3:39:26 PM7/23/19
to Jenkins Developers
With Dependabot acquisition by GitHub, the project got some development boost.
Unfortunately, there is still no support of org-wide configurations, so we cannot just put defaults to https://github.com/jenkinsci/.github 
But we could at least put some samples there.

I would also like to enable Dependabot for Jenkins Test Harness if nobody is against.

Once Jesse finishes his work on https://github.com/jenkinsci/bom/ , it would be great to combine Dependabot and plugins with BOM (especially for Pipeline which is nightmare to handle in Dependabot).

BR, Oleg


On Monday, June 10, 2019 at 7:04:08 PM UTC+2, Oleg Nenashev wrote:
done!

On Mon, Jun 10, 2019 at 6:40 PM Basil Crow <m...@basilcrow.com> wrote:
On Wednesday, May 22, 2019 at 11:47:09 PM UTC-7, Oleg Nenashev wrote:
I am fine with going forward with enabling Dependabot for a wider set of plugins.

 Can you please add the following repositories:


Thanks,
Basil

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/XMllKuWLO_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

Steve Hill

unread,
Jul 25, 2019, 12:24:28 AM7/25/19
to Jenkins Developers
Could we also enable Dependabot for https://github.com/jenkinsci/gradle-jpi-plugin?

Best,
Steve


On Tuesday, July 23, 2019 at 12:39:26 PM UTC-7, Oleg Nenashev wrote:
With Dependabot acquisition by GitHub, the project got some development boost.
Unfortunately, there is still no support of org-wide configurations, so we cannot just put defaults to https://github.com/jenkinsci/.github 
But we could at least put some samples there.

I would also like to enable Dependabot for Jenkins Test Harness if nobody is against.

Once Jesse finishes his work on https://github.com/jenkinsci/bom/ , it would be great to combine Dependabot and plugins with BOM (especially for Pipeline which is nightmare to handle in Dependabot).

BR, Oleg


On Monday, June 10, 2019 at 7:04:08 PM UTC+2, Oleg Nenashev wrote:
done!

On Mon, Jun 10, 2019 at 6:40 PM Basil Crow <m...@basilcrow.com> wrote:
On Wednesday, May 22, 2019 at 11:47:09 PM UTC-7, Oleg Nenashev wrote:
I am fine with going forward with enabling Dependabot for a wider set of plugins.

 Can you please add the following repositories:


Thanks,
Basil

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/XMllKuWLO_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkin...@googlegroups.com.

Oleg Nenashev

unread,
Jul 25, 2019, 3:01:03 AM7/25/19
to Jenkins Developers
Hi, done

I enabled Dependabot for Gradle JPI Plugin, Role Strategy Plugin and Jenkins Test Harness. 
Also added Log CLI Plugin as it was requested by Martin Reinhardt in GitHub.

Basically every maintainer with Admin permissions can enable Dependabot on his/her own:
  1. Enable the Dependabot GitHub application for the repo
  2. Add a .dependabot/config.yml file to the repo (docs). Once added, the Dependabot will pick up the repo automatically
For new Dependabot requests I suggest to stop adding the configurations manually in DependaBot Web UI.
Let's use .dependabot/config.yml only. 

BR, Oleg

Jesse Glick

unread,
Jul 25, 2019, 1:45:33 PM7/25/19
to Jenkins Dev
On Thu, Jul 25, 2019 at 3:01 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> Basically every maintainer with Admin permissions can enable Dependabot on his/her own:

And if you lack admin permissions, just file an `INFRA` ticket requesting it.

Oleg Nenashev

unread,
Jan 24, 2020, 7:41:17 AM1/24/20
to Jenkins Developers
Hi All,

Just in case somebody is interested, today we will have an online meetup about Dependabot in Jenkins.

Please join us if you are interested!

Best regards,
Oleg


On Thursday, July 25, 2019 at 7:45:33 PM UTC+2, Jesse Glick wrote:

Oleg Nenashev

unread,
Jun 24, 2020, 5:03:25 PM6/24/20
to Jenkins Developers
FTR Dependabot is now embedded into GitHub. Probably it is a good time to prepare official documentation https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/

Oleg Nenashev

unread,
Oct 8, 2020, 7:29:35 AM10/8/20
to Jenkins Developers
I have started https://github.com/jenkinsci/.github/pull/40 with documentation notes. If anyone is interested to contribute and share your notes / best practices, please do so!
Later we can move the page to https://www.jenkins.io/doc/developer/plugin-development/

Baptiste Mathus

unread,
Oct 19, 2020, 7:57:08 AM10/19/20
to Jenkins Developers
Hi all, 

FYI, as I was using the Dependabot admin UI, I just requested Dependabot to file automated PRs on a number of plugins:


I was going to configure Dependabot on my buildtriggerbadge plugin, but then realized Dependabot now has this nice feature to file automated PRs to migrate from the previous Dependabot settings to the native one.

image.png

If anybody still has the previous configuration, and would like to get an automated PR, please let me/us know and I can request it.

HTH
Cheers

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/af5db0c2-3be6-4efb-b017-c06cbe8ce912n%40googlegroups.com.

Jesse Glick

unread,
Oct 19, 2020, 10:44:54 AM10/19/20
to Jenkins Dev
On Mon, Oct 19, 2020 at 7:57 AM Baptiste Mathus <m...@batmat.net> wrote:
> If anybody still has the previous configuration, and would like to get an automated PR, please let me/us know and I can request it.

I would certainly want this but have no idea which repositories I
might “own” which are configured with the preview app. Is there any
harm in just requesting the conversion PR for every remaining repo?

Ullrich Hafner

unread,
Oct 19, 2020, 3:08:32 PM10/19/20
to Jenkins Developers
I think that this can be done globally: for each repository a PR will be generated. So in order to finish the transition the repo owner still needs to merge the PR. However, I do not find a button to run this for all repositories :-(
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3Z_UnaBsWpg%2BwXhut7YOvZUG9X8dsTB-7EXfouOqypvA%40mail.gmail.com.

Baptiste Mathus

unread,
Oct 20, 2020, 12:05:44 PM10/20/20
to Jenkins Developers
I've just gone ahead and clicked on all repositories where the button was available.

So given I don't have an easy way to request review from current active maintainers.
So Jesse or any maintainer: please review the list :

And look for any plugin you're maintaining.

AFAIU there's unfortunately no way to generate from this UI an automated PR for all repositories and not just the ones who already had configured Dependabot (now called "dependabot-preview").

But if there's interest, I'm happy to script something to file such a PR on multiple repos.
I guess I'm not going to do for the whole org upfront just to avoid potential people complaints. (?)

I'm not yet fully sure whether Oleg's concern on jenkins.version is still current.
It _seems_ not anymore in the "dependabot native" app. But it's hard to know whether this is something GitHub will add back parity for.
🤔
And even so, I agree with Jesse that it would be better to request bumps with some LTS version scheme requirement, rather than making them all ignored. (See Oleg's PR earlier in this thread for context).

Anyway, looking at the positive side: thanks a lot Oleg again for making this happen.
I think overall, whatever happens, keeping dependencies more up-to-date is a great plus for the health of the Jenkins ecosystem.

-- Baptiste

Chris Kilding

unread,
Nov 2, 2020, 1:34:50 PM11/2/20
to jenkin...@googlegroups.com
I enabled the native Dependabot version updates (the experimental feature) on my plugin today. Overall it's extremely useful and working well! I expect I'll soon wonder how I ever managed without it.

Couple of thoughts:

1. The initial splurge of PRs spawns a lot of builds, so it's helpful that Dependabot has limited itself to opening 5 PRs at a time (you can raise this limit in configuration if you like). Obviously this is only a one-time concern on the day that you enable it, but it could spam ci.jenkins.io if enabled on lots of plugins at once.
2. You have to be a bit careful when merging if you are using dependencies that interact. E.g. if you're using BOM (which contains Jackson), and a plugin that has particular ideas about the Jackson version it wants. So you can't just point-and-merge, even though they look like one-liner changes that seem easy to reason about.
3. Because Dependabot makes it easy to stay up to date, it's tempting to charge forward and take the latest version of everything suggested - providing the build passes. But is that wise? Do we as plugin authors need to hang back on some changes with the LTS support policy in mind? (For example, should I advance to depending on BOM version 2.249.x if the LTS policy says to support n-3 LTS versions?)

Chris

Mark Waite

unread,
Nov 2, 2020, 1:50:11 PM11/2/20
to jenkinsci-dev
On Mon, Nov 2, 2020 at 11:34 AM Chris Kilding <chris+...@chriskilding.com> wrote:
I enabled the native Dependabot version updates (the experimental feature) on my plugin today. Overall it's extremely useful and working well! I expect I'll soon wonder how I ever managed without it.

Couple of thoughts:

1. The initial splurge of PRs spawns a lot of builds, so it's helpful that Dependabot has limited itself to opening 5 PRs at a time (you can raise this limit in configuration if you like). Obviously this is only a one-time concern on the day that you enable it, but it could spam ci.jenkins.io if enabled on lots of plugins at once.
2. You have to be a bit careful when merging if you are using dependencies that interact. E.g. if you're using BOM (which contains Jackson), and a plugin that has particular ideas about the Jackson version it wants. So you can't just point-and-merge, even though they look like one-liner changes that seem easy to reason about.
3. Because Dependabot makes it easy to stay up to date, it's tempting to charge forward and take the latest version of everything suggested - providing the build passes. But is that wise? Do we as plugin authors need to hang back on some changes with the LTS support policy in mind? (For example, should I advance to depending on BOM version 2.249.x if the LTS policy says to support n-3 LTS versions?)


https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/ describes the compromises involved in the choice of minimum Jenkins version for a plugin.  Jenkins 2.222.1 and Jenkins 2.235.1 are the currently recommended baseline versions.  I think that the recommendations on that page are good for most plugins.  Notable exceptions are described on the page (need an API that is only available in a newer core, etc.).

The pull requests that submitted page also contain good discussion if you'd like more information - https://github.com/jenkins-infra/jenkins.io/pull/3643 and https://github.com/jenkins-infra/jenkins.io/pull/3655

Mark Waite

Jesse Glick

unread,
Nov 2, 2020, 2:11:22 PM11/2/20
to Jenkins Dev
On Mon, Nov 2, 2020 at 1:34 PM Chris Kilding
<chris+...@chriskilding.com> wrote:
> should I advance to depending on BOM version 2.249.x

Note that Dependabot will not _offer_ such a bump—only bumps within,
say, `bom-2.235.x`. It is up to you to select a `bom-*.x` matching
your current `jenkins.version`, and to decide when to switch to a
newer LTS line.

Baptiste Mathus

unread,
Dec 10, 2020, 5:58:14 PM12/10/20
to Jenkins Developers
Hi all, 

I wanted to raise a discussion on this and thought I'd fork off this answer from Jesse on Oleg's thread.

I see Jesse already configured Dependabot for Xstream: https://github.com/jenkinsci/jenkins/commit/2440a34d8f2ba5626d734c735cb4fc63040c11de

Should we start adding all core components, like the parent pom, internal or test tools like JTH,  and some dependencies we think are safe (build-time things like Maven plugins, I assume)?

AIUI, we would be able to agree on an allowList approach? I.e. adding specific dependencies we want auto-updated (excluding any that's unlisted).

Side note on this: I think if we agree to go this path, it would be great to find a way modify the Core Pipeline so the essentials.yaml values are sourced from some pom.xml (for ATH version) so Dependabot can understand and update this too.
This way, we'd be getting automated updates for https://github.com/jenkinsci/jenkins/blob/53f300d5ec07eb5efa3774d3f12455615d2f3450/essentials.yml#L4-L5 too, which bit us in the arse recently on the latest LTS prep IIRC.

WDYT?


IIUC, we could kinda take an allowList approach on specific components.

Le jeu. 21 févr. 2019 à 15:40, Jesse Glick <jgl...@cloudbees.com> a écrit :
On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev <o.v.ne...@gmail.com> wrote:
> I propose to focus on development tools

Since the primary use case is offering updates to plugin repositories,
I would suggest including at least one example of `*-plugin`.

The question is which dependencies ought to be eligible for upgrade. I
do not think we want to update Jenkins core or plugin dependencies
gratuitously, since this would limit availability of new releases with
only modest productivity gain: more realistic functional tests, less
distance from `master` to whatever `plugin-compat-tester` would use.

Definitely we can freely upgrade the parent POM. I would be happy for
such updates to be auto-merged in fact, so long as the build passes
obviously.

> pre-1.0 projects only

Or just plugins that (a) have fairly low installation count, (b) are
maintained by people actively participating in the trial.

> More repositories can be added if somebody is interested to participate in the Dependabot evaluation.

Sign me up!

I _do_ need to make sure I get notifications of these PRs in
Octobox.io, if they are not simply automerged. Merely watching a
repository is not enough—GH has autosubscribed me to hundreds of
repos, and the resulting thousands of notifications go to /dev/null.
Maybe Dependabot can be configured to request me as a reviewer?


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Oleg Nenashev

unread,
Dec 10, 2020, 7:01:35 PM12/10/20
to JenkinsCI Developers
I am +1. We should finally move forward with Dependabot for dependencies we considers safe and important to be kept up to date. Allow list is a good way to go, we have a sizeable number if deps. 

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/XMllKuWLO_8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%40mail.gmail.com.

Tim Jacomb

unread,
Dec 11, 2020, 2:31:34 AM12/11/20
to jenkin...@googlegroups.com
I’m fine with adding more,

We could also try a deny list too and see how it goes

Jesse Glick

unread,
Dec 11, 2020, 9:39:31 AM12/11/20
to Jenkins Dev
I would suggest using a deny list. You will get an initial spray of
PRs, mostly to `bom/pom.xml`. Some we will reject as unsafe (likely
breaking change for plugins relying on core classpath), which we can
then add as exclusions in Dependabot config. But we may be surprised
by helpful updates that we would never have thought to add to an allow
list.

Jesse Glick

unread,
Dec 11, 2020, 9:42:01 AM12/11/20
to Jenkins Dev
On Thu, Dec 10, 2020 at 5:58 PM Baptiste Mathus <m...@batmat.net> wrote:
> modify the Core Pipeline so the essentials.yaml values are sourced from some pom.xml (for ATH version) so Dependabot can understand and update this too.

Yes, or switch it to a Git submodule which I think it could also handle.

The image is trickier. Could perhaps define a dummy `Dockerfile`
containing only a `FROM` directive, which Dependabot ought to grok.

Baptiste Mathus

unread,
Dec 11, 2020, 4:14:36 PM12/11/20
to Jenkins Developers, Oleg Nenashev
OK, I've just filed https://github.com/jenkinsci/jenkins/pull/5108 as Jesse and Tim are suggesting we go the "deny" path.

I think indeed the idea to deny/ignore the dependency that we know they shouldn't be automated is probably good as we may see some interesting things.

@Oleg Nenashev if you feel strongly we should really add things more progressively, just tell me. I'm fine and I'll adjust the PR or create a new one with a proposal of first deps.

Thanks all!

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages