Proposal: Automating dependency management for repositories inside the jenkinsci org

[Jesse Glick-4]

On Mon, Nov 2, 2020 at 1:34 PM Chris Kilding
<[hidden email]> 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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0pWXSzM4DLqA-DeJr%3D3OXb2CcLGp-8%2BybPEwUdjhOLMQ%40mail.gmail.com.

[Baptiste MATHUS]

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 <[hidden email]> a écrit :

On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%40mail.gmail.com.

[Oleg Nenashev]

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. 

On Thu, Dec 10, 2020, 23:58 Baptiste Mathus <[hidden email]> wrote:

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 <[hidden email]> a écrit :

On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDNgdKA2A-85n-ePFMOe7UdRE9%3DCRp%3DvXrP717Jrf4QTA%40mail.gmail.com.

I’m fine with adding more,

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

On Fri, 11 Dec 2020 at 00:01, Oleg Nenashev <[hidden email]> wrote:

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. 

On Thu, Dec 10, 2020, 23:58 Baptiste Mathus <[hidden email]> wrote:

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 <[hidden email]> a écrit :

On Thu, Feb 21, 2019 at 8:43 AM Oleg Nenashev <[hidden email]> 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2pcB-%2BGsnJFKO7sR3drv3F43ADqqwAW0RU_bJUrpKEuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7JwFRXk%2BX_5q8QDXK30Nif1fKLXbOWKWNWZUFFSXSjew%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDNgdKA2A-85n-ePFMOe7UdRE9%3DCRp%3DvXrP717Jrf4QTA%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BieuRiMfe3b-Zn81PXPWJAe4qdpsVocCnVahk27srd-JYQ%40mail.gmail.com.

[Jesse Glick-4]

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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3v5CgCcqf%3DMysY8N9-AOpOrFkqh%2BuNLxbSx%3DVw3Q%2Bynw%40mail.gmail.com.

[Jesse Glick-4]

On Thu, Dec 10, 2020 at 5:58 PM Baptiste Mathus <[hidden email]> 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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0iTc9s74ewzs8Ot21nn4nDoSJfZV%3DZo%2B_hLAGDiJWyhQ%40mail.gmail.com.

[Baptiste MATHUS]

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.

[hidden email] 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!

Le ven. 11 déc. 2020 à 15:39, Jesse Glick <[hidden email]> a écrit :

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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3v5CgCcqf%3DMysY8N9-AOpOrFkqh%2BuNLxbSx%3DVw3Q%2Bynw%40mail.gmail.com.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5uS7Y8PP76Lk2yZhSsACKhizRcEFOB9YCKLw6DRZK-0g%40mail.gmail.com.