On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)redhat.com&gt; wrote: Hello, would the Wildfly team be interested in (or opposed to) receiving component upgrade PRs, which would be created automatically when a new component version is released? (I'm talking about new micro/SP versions, depending on the component, i.e. version that could be reasonably expected to be suitable for consumption, without issues like breaking API changes etc.) I'm working on a tool [1], which is able to provide these PRs. The tool scans given project for dependencies, and then looks at what versions of those dependencies are available in Maven Central and possibly other repositories. I can configure rules for each dependency, that specify what versions should be considered viable for upgrading (e.g. for "org.picketlink:*" we would only offer new "SP" builds in the same micro, for most of the other dependencies we would only offer new micros, and some artifacts would perhaps be blacklisted). Example of this configuration is here [2]. Advantages that I believe could be gained from this: * It would bring us an advantage of having new component micros tested soon in Wildfly, and therefore having more confidence when we need to do the same upgrades in EAP. * It would also help in preventing EAP running ahead of Wildfly in component versions, which happens occasionally. EAP release coordinator usually spots this problem and creates missing PR in Wildfly, but it's a manual check and therefore a small risk remains. * It would ensure Wildfly is consuming latest component fixes. You can review PRs generated last week in my fork of Wildfly [3]. It's a work in progress, I expect the tool and it's configuration would evolve according to experiences we would get from using it... What do you think? [1] https://github.com/TomasHofman/maven-dependency-updater/ [2] https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... [3] https://github.com/TomasHofman/wildfly/pulls -- Tomas Hofman Software Engineer, JBoss SET Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

I took a quick look at the README of Tomas's project and the main difference seems to be the opt-in approach, as opposed to Dependabot's opt-out approach. Dependabot attempts to update everything, and you have to opt out of certain dependencies (by commenting in pull requests!). If you have multiple repositories with similar needs, you have to opt out for each repository again and again. If I understand Tomas's project correctly, you can define configuration upfront, and it won't touch dependencies that are not configured. Tomas, please correct me if I'm wrong here :-) LT On 02. 09. 19 11:45, Rostislav Svoboda wrote: > This tools sounds similar to > https://github.com/marketplace/dependabot-preview > What are the main differences ? > > Rostislav > >> On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)redhat.com >> <mailto:thofman@redhat.com>> wrote: >> >> Hello, >> >> would the Wildfly team be interested in (or opposed to) receiving >> component >> upgrade PRs, which would be created automatically when a new >> component version >> is released? (I'm talking about new micro/SP versions, depending on the >> component, i.e. version that could be reasonably expected to be >> suitable for >> consumption, without issues like breaking API changes etc.) >> >> I'm working on a tool [1], which is able to provide these PRs. >> >> The tool scans given project for dependencies, and then looks at >> what versions >> of those dependencies are available in Maven Central and possibly other >> repositories. I can configure rules for each dependency, that >> specify what >> versions should be considered viable for upgrading (e.g. for >> "org.picketlink:*" >> we would only offer new "SP" builds in the same micro, for most of >> the other >> dependencies we would only offer new micros, and some artifacts >> would perhaps >> be blacklisted). Example of this configuration is here [2]. >> >> Advantages that I believe could be gained from this: >> >> * It would bring us an advantage of having new component micros >> tested soon in >> Wildfly, and therefore having more confidence when we need to do the >> same >> upgrades in EAP. >> >> * It would also help in preventing EAP running ahead of Wildfly in >> component >> versions, which happens occasionally. EAP release coordinator >> usually spots >> this problem and creates missing PR in Wildfly, but it's a manual >> check and >> therefore a small risk remains. >> >> * It would ensure Wildfly is consuming latest component fixes. >> >> You can review PRs generated last week in my fork of Wildfly [3]. >> >> It's a work in progress, I expect the tool and it's configuration >> would evolve >> according to experiences we would get from using it... >> >> What do you think? >> >> [1] https://github.com/TomasHofman/maven-dependency-updater/ >> [2] >> https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >> [3] https://github.com/TomasHofman/wildfly/pulls >> >> -- >> Tomas Hofman >> Software Engineer, JBoss SET >> Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 2 Sep 2019, at 15:44, Tomas Hofman <thofman(a)redhat.com&gt; wrote: Yes, to me the main difference is that dependabot doesn't allow to configure per component "rules" limiting when you want to upgrade.

E.g. I want to be able to say: for artifacts with G:A "org.picketlink:*", only upgrade if there's a higher version starting with "2.5.5" and having qualifier that matches regex "SP-\\d". Tomas On 02/09/2019 11:45, Rostislav Svoboda wrote: > This tools sounds similar to https://github.com/marketplace/dependabot-preview <https://github.com/marketplace/dependabot-preview> > What are the main differences ? > Rostislav >> On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com> <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote: >> >> Hello, >> >> would the Wildfly team be interested in (or opposed to) receiving component >> upgrade PRs, which would be created automatically when a new component version >> is released? (I'm talking about new micro/SP versions, depending on the >> component, i.e. version that could be reasonably expected to be suitable for >> consumption, without issues like breaking API changes etc.) >> >> I'm working on a tool [1], which is able to provide these PRs. >> >> The tool scans given project for dependencies, and then looks at what versions >> of those dependencies are available in Maven Central and possibly other >> repositories. I can configure rules for each dependency, that specify what >> versions should be considered viable for upgrading (e.g. for "org.picketlink:*" >> we would only offer new "SP" builds in the same micro, for most of the other >> dependencies we would only offer new micros, and some artifacts would perhaps >> be blacklisted). Example of this configuration is here [2]. >> >> Advantages that I believe could be gained from this: >> >> * It would bring us an advantage of having new component micros tested soon in >> Wildfly, and therefore having more confidence when we need to do the same >> upgrades in EAP. >> >> * It would also help in preventing EAP running ahead of Wildfly in component >> versions, which happens occasionally. EAP release coordinator usually spots >> this problem and creates missing PR in Wildfly, but it's a manual check and >> therefore a small risk remains. >> >> * It would ensure Wildfly is consuming latest component fixes. >> >> You can review PRs generated last week in my fork of Wildfly [3]. >> >> It's a work in progress, I expect the tool and it's configuration would evolve >> according to experiences we would get from using it... >> >> What do you think? >> >> [1] https://github.com/TomasHofman/maven-dependency-updater/ >> [2] >> https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >> [3] https://github.com/TomasHofman/wildfly/pulls >> >> -- >> Tomas Hofman >> Software Engineer, JBoss SET >> Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Tomas Hofman Software Engineer, JBoss SET Red Hat

Hi Tomas, Can this generate emails to this list instead of PRs? Processing PRs is expensive, both in terms of burden on our somewhat overburdened CI and in terms of forcing mergers to deal with a PR queue.  I'm not opposed to ending up getting PRs but I'd like to see any system producing acceptable inputs before we let it at the PR queue.

I'm glad to see the discussion of configurable rules, as that's quite important.  I wouldn't like to see anything proposed except micro version updates or less than micro. No minors. If that's inappropriate for some component then that could be adjusted for that one, but the default should be micros only.

I also think some sort of time delay is appropriate, probably at least a week. Having an automated system race with the humans working on WildFly would be annoying. Github already notifies us of possible upgrades to components with CVEs.

Best regards, Brian On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com>> wrote: Hello, would the Wildfly team be interested in (or opposed to) receiving component upgrade PRs, which would be created automatically when a new component version is released? (I'm talking about new micro/SP versions, depending on the component, i.e. version that could be reasonably expected to be suitable for consumption, without issues like breaking API changes etc.) I'm working on a tool [1], which is able to provide these PRs. The tool scans given project for dependencies, and then looks at what versions of those dependencies are available in Maven Central and possibly other repositories. I can configure rules for each dependency, that specify what versions should be considered viable for upgrading (e.g. for "org.picketlink:*" we would only offer new "SP" builds in the same micro, for most of the other dependencies we would only offer new micros, and some artifacts would perhaps be blacklisted). Example of this configuration is here [2]. Advantages that I believe could be gained from this: * It would bring us an advantage of having new component micros tested soon in Wildfly, and therefore having more confidence when we need to do the same upgrades in EAP. * It would also help in preventing EAP running ahead of Wildfly in component versions, which happens occasionally. EAP release coordinator usually spots this problem and creates missing PR in Wildfly, but it's a manual check and therefore a small risk remains. * It would ensure Wildfly is consuming latest component fixes. You can review PRs generated last week in my fork of Wildfly [3]. It's a work in progress, I expect the tool and it's configuration would evolve according to experiences we would get from using it... What do you think? [1] https://github.com/TomasHofman/maven-dependency-updater/ [2] https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... [3] https://github.com/TomasHofman/wildfly/pulls -- Tomas Hofman Software Engineer, JBoss SET Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat

An e-mail report would be really good, component leads may want to apply the update to their own projects first to double check. On Tue, Sep 3, 2019 at 9:55 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com>> wrote: On 02/09/2019 17:55, Brian Stansberry wrote: > Hi Tomas, > > Can this generate emails to this list instead of PRs? Processing PRs is > expensive, both in terms of burden on our somewhat overburdened CI and in terms > of forcing mergers to deal with a PR queue.  I'm not opposed to ending up > getting PRs but I'd like to see any system producing acceptable inputs before > we let it at the PR queue. That's a good idea, we could definitely start with an email report. Would give us chance to get the configuration in shape without cluttering the PR queue. I will post it. I was thinking about what is the most easily consumable form to deliver this. If we do manual review first, than perhaps single large PRs is better than separate PRs for each upgrade, to minimize CI burden and generate less noise for PR reviewers. > > I'm glad to see the discussion of configurable rules, as that's quite > important.  I wouldn't like to see anything proposed except micro version > updates or less than micro. No minors. If that's inappropriate for some > component then that could be adjusted for that one, but the default should be > micros only. Agree. > > I also think some sort of time delay is appropriate, probably at least a week. > Having an automated system race with the humans working on WildFly would be > annoying. Github already notifies us of possible upgrades to components with CVEs. I also think long interval is better. Even maybe rather than running on regular intervals it could be triggered manually by RC after every EAP release or during some part of the release cycle. Tomas > > Best regards, > Brian > > > On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com> > <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote: > >     Hello, > >     would the Wildfly team be interested in (or opposed to) receiving component >     upgrade PRs, which would be created automatically when a new component version >     is released? (I'm talking about new micro/SP versions, depending on the >     component, i.e. version that could be reasonably expected to be suitable for >     consumption, without issues like breaking API changes etc.) > >     I'm working on a tool [1], which is able to provide these PRs. > >     The tool scans given project for dependencies, and then looks at what versions >     of those dependencies are available in Maven Central and possibly other >     repositories. I can configure rules for each dependency, that specify what >     versions should be considered viable for upgrading (e.g. for >     "org.picketlink:*" >     we would only offer new "SP" builds in the same micro, for most of the other >     dependencies we would only offer new micros, and some artifacts would perhaps >     be blacklisted). Example of this configuration is here [2]. > >     Advantages that I believe could be gained from this: > >     * It would bring us an advantage of having new component micros tested soon in >     Wildfly, and therefore having more confidence when we need to do the same >     upgrades in EAP. > >     * It would also help in preventing EAP running ahead of Wildfly in component >     versions, which happens occasionally. EAP release coordinator usually spots >     this problem and creates missing PR in Wildfly, but it's a manual check and >     therefore a small risk remains. > >     * It would ensure Wildfly is consuming latest component fixes. > >     You can review PRs generated last week in my fork of Wildfly [3]. > >     It's a work in progress, I expect the tool and it's configuration would evolve >     according to experiences we would get from using it... > >     What do you think? > >     [1] https://github.com/TomasHofman/maven-dependency-updater/ >     [2] > https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >     [3] https://github.com/TomasHofman/wildfly/pulls > >     -- >     Tomas Hofman >     Software Engineer, JBoss SET >     Red Hat >     _______________________________________________ >     wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -- Tomas Hofman Software Engineer, JBoss SET Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

That would be really useful as we should be coordinating these via the component leads rather than just at the very end. On Tue, Sep 3, 2019 at 10:23 AM Carlo de Wolf <cdewolf(a)redhat.com <mailto:cdewolf@redhat.com>> wrote: The tool is not WildFly specific, so it should be able to run on any project. Carlo On 03-09-19 11:01, Darran Lofthouse wrote: > An e-mail report would be really good, component leads may want to apply > the update to their own projects first to double check. > > On Tue, Sep 3, 2019 at 9:55 AM Tomas Hofman <thofman(a)redhat.com > <mailto:thofman@redhat.com>> wrote: > > > > On 02/09/2019 17:55, Brian Stansberry wrote: > > Hi Tomas, > > > > Can this generate emails to this list instead of PRs? Processing > PRs is > > expensive, both in terms of burden on our somewhat overburdened CI > and in terms > > of forcing mergers to deal with a PR queue.  I'm not opposed to > ending up > > getting PRs but I'd like to see any system producing acceptable > inputs before > > we let it at the PR queue. > > That's a good idea, we could definitely start with an email report. > Would give > us chance to get the configuration in shape without cluttering the PR > queue. I > will post it. > > I was thinking about what is the most easily consumable form to > deliver this. > If we do manual review first, than perhaps single large PRs is better > than > separate PRs for each upgrade, to minimize CI burden and generate > less noise > for PR reviewers. > > > > > I'm glad to see the discussion of configurable rules, as that's quite > > important.  I wouldn't like to see anything proposed except micro > version > > updates or less than micro. No minors. If that's inappropriate for > some > > component then that could be adjusted for that one, but the default > should be > > micros only. > > Agree. > > > > > I also think some sort of time delay is appropriate, probably at > least a week. > > Having an automated system race with the humans working on WildFly > would be > > annoying. Github already notifies us of possible upgrades to > components with CVEs. > > I also think long interval is better. Even maybe rather than running > on regular > intervals it could be triggered manually by RC after every EAP > release or > during some part of the release cycle. > > > Tomas > > > > > Best regards, > > Brian > > > > > > On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com > <mailto:thofman@redhat.com> > > <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote: > > > >     Hello, > > > >     would the Wildfly team be interested in (or opposed to) > receiving component > >     upgrade PRs, which would be created automatically when a new > component version > >     is released? (I'm talking about new micro/SP versions, > depending on the > >     component, i.e. version that could be reasonably expected to be > suitable for > >     consumption, without issues like breaking API changes etc.) > > > >     I'm working on a tool [1], which is able to provide these PRs. > > > >     The tool scans given project for dependencies, and then looks > at what versions > >     of those dependencies are available in Maven Central and > possibly other > >     repositories. I can configure rules for each dependency, that > specify what > >     versions should be considered viable for upgrading (e.g. for > >     "org.picketlink:*" > >     we would only offer new "SP" builds in the same micro, for most > of the other > >     dependencies we would only offer new micros, and some artifacts > would perhaps > >     be blacklisted). Example of this configuration is here [2]. > > > >     Advantages that I believe could be gained from this: > > > >     * It would bring us an advantage of having new component micros > tested soon in > >     Wildfly, and therefore having more confidence when we need to > do the same > >     upgrades in EAP. > > > >     * It would also help in preventing EAP running ahead of Wildfly > in component > >     versions, which happens occasionally. EAP release coordinator > usually spots > >     this problem and creates missing PR in Wildfly, but it's a > manual check and > >     therefore a small risk remains. > > > >     * It would ensure Wildfly is consuming latest component fixes. > > > >     You can review PRs generated last week in my fork of Wildfly [3]. > > > >     It's a work in progress, I expect the tool and it's > configuration would evolve > >     according to experiences we would get from using it... > > > >     What do you think? > > > >     [1] https://github.com/TomasHofman/maven-dependency-updater/ > >     [2] > > > https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... > >     [3] https://github.com/TomasHofman/wildfly/pulls > > > >     -- > >     Tomas Hofman > >     Software Engineer, JBoss SET > >     Red Hat > >     _______________________________________________ > >     wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > -- > > Brian Stansberry > > Manager, Senior Principal Software Engineer > > Red Hat > > -- > Tomas Hofman > Software Engineer, JBoss SET > Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev

Our elytron-web repo would also be interesting - we don't spend a lot of time in that repo so reminders things need an update could help there. On Tue, Sep 3, 2019 at 2:53 PM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com>> wrote: Running it on wildfly-elytron 1.x branch gives quite brief report: Generated at 15:42:49 2019-09-03 org.apache.commons:commons-lang3:3.8 -> 3.8.1 org.jboss.spec.javax.json:jboss-json-api_1.0_spec:1.0.0.Final -> 1.0.1.Final org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:1.0.1.Final -> 1.0.2.Final org.wildfly.common:wildfly-common:1.5.1.Final -> 1.5.2.Final Are you interested in any other component? On 03/09/2019 11:31, Darran Lofthouse wrote: > That would be really useful as we should be coordinating these via the > component leads rather than just at the very end. > > On Tue, Sep 3, 2019 at 10:23 AM Carlo de Wolf <cdewolf(a)redhat.com <mailto:cdewolf@redhat.com> > <mailto:cdewolf@redhat.com <mailto:cdewolf@redhat.com>>> wrote: > >     The tool is not WildFly specific, so it should be able to run on any project. > >     Carlo > >     On 03-09-19 11:01, Darran Lofthouse wrote: >>     An e-mail report would be really good, component leads may want to apply >>     the update to their own projects first to double check. >> >>     On Tue, Sep 3, 2019 at 9:55 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com> >>     <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote: >> >> >> >>         On 02/09/2019 17:55, Brian Stansberry wrote: >>         > Hi Tomas, >>         > >>         > Can this generate emails to this list instead of PRs? Processing >>         PRs is >>         > expensive, both in terms of burden on our somewhat overburdened CI >>         and in terms >>         > of forcing mergers to deal with a PR queue.  I'm not opposed to >>         ending up >>         > getting PRs but I'd like to see any system producing acceptable >>         inputs before >>         > we let it at the PR queue. >> >>         That's a good idea, we could definitely start with an email report. >>         Would give >>         us chance to get the configuration in shape without cluttering the PR >>         queue. I >>         will post it. >> >>         I was thinking about what is the most easily consumable form to >>         deliver this. >>         If we do manual review first, than perhaps single large PRs is better >>         than >>         separate PRs for each upgrade, to minimize CI burden and generate >>         less noise >>         for PR reviewers. >> >>         > >>         > I'm glad to see the discussion of configurable rules, as that's quite >>         > important.  I wouldn't like to see anything proposed except micro >>         version >>         > updates or less than micro. No minors. If that's inappropriate for >>         some >>         > component then that could be adjusted for that one, but the default >>         should be >>         > micros only. >> >>         Agree. >> >>         > >>         > I also think some sort of time delay is appropriate, probably at >>         least a week. >>         > Having an automated system race with the humans working on WildFly >>         would be >>         > annoying. Github already notifies us of possible upgrades to >>         components with CVEs. >> >>         I also think long interval is better. Even maybe rather than running >>         on regular >>         intervals it could be triggered manually by RC after every EAP >>         release or >>         during some part of the release cycle. >> >> >>         Tomas >> >>         > >>         > Best regards, >>         > Brian >>         > >>         > >>         > On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com> >>         <mailto:thofman@redhat.com <mailto:thofman@redhat.com>> >>         > <mailto:thofman@redhat.com <mailto:thofman@redhat.com> <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>>> wrote: >>         > >>         >     Hello, >>         > >>         >     would the Wildfly team be interested in (or opposed to) >>         receiving component >>         >     upgrade PRs, which would be created automatically when a new >>         component version >>         >     is released? (I'm talking about new micro/SP versions, >>         depending on the >>         >     component, i.e. version that could be reasonably expected to be >>         suitable for >>         >     consumption, without issues like breaking API changes etc.) >>         > >>         >     I'm working on a tool [1], which is able to provide these PRs. >>         > >>         >     The tool scans given project for dependencies, and then looks >>         at what versions >>         >     of those dependencies are available in Maven Central and >>         possibly other >>         >     repositories. I can configure rules for each dependency, that >>         specify what >>         >     versions should be considered viable for upgrading (e.g. for >>         >     "org.picketlink:*" >>         >     we would only offer new "SP" builds in the same micro, for most >>         of the other >>         >     dependencies we would only offer new micros, and some artifacts >>         would perhaps >>         >     be blacklisted). Example of this configuration is here [2]. >>         > >>         >     Advantages that I believe could be gained from this: >>         > >>         >     * It would bring us an advantage of having new component micros >>         tested soon in >>         >     Wildfly, and therefore having more confidence when we need to >>         do the same >>         >     upgrades in EAP. >>         > >>         >     * It would also help in preventing EAP running ahead of Wildfly >>         in component >>         >     versions, which happens occasionally. EAP release coordinator >>         usually spots >>         >     this problem and creates missing PR in Wildfly, but it's a >>         manual check and >>         >     therefore a small risk remains. >>         > >>         >     * It would ensure Wildfly is consuming latest component fixes. >>         > >>         >     You can review PRs generated last week in my fork of Wildfly [3]. >>         > >>         >     It's a work in progress, I expect the tool and it's >>         configuration would evolve >>         >     according to experiences we would get from using it... >>         > >>         >     What do you think? >>         > >>         >     [1] https://github.com/TomasHofman/maven-dependency-updater/ >>         >     [2] >>         > >> https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >>         >     [3] https://github.com/TomasHofman/wildfly/pulls >>         > >>         >     -- >>         >     Tomas Hofman >>         >     Software Engineer, JBoss SET >>         >     Red Hat >>         >     _______________________________________________ >>         >     wildfly-dev mailing list >>         > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >>         <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>> >>         > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>         > >>         > >>         > >>         > -- >>         > Brian Stansberry >>         > Manager, Senior Principal Software Engineer >>         > Red Hat >> >>         -- >>         Tomas Hofman >>         Software Engineer, JBoss SET >>         Red Hat >>         _______________________________________________ >>         wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >>     _______________________________________________ >>     wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Tomas Hofman Software Engineer, JBoss SET Red Hat

I was thinking about what is the most easily consumable form to deliver this. If we do manual review first, than perhaps single large PRs is better than separate PRs for each upgrade, to minimize CI burden and generate less noise for PR reviewers. Looking at the first report I think we've got a way to go before we get to PRs. :) In general I don't think PRs with a lot of upgrades will be useful, as they are not actionable unless 100% of the upgrades are valid.  OTOH I can see how having 20 PRs for different CXF components would be annoying and would drown CI for some hours. Something slick might be for the tool to understand the version property strings and aggregate based on that.

I see three categories of upgrades: 1) Projects that the main WF devs control, so we're doing the release and the upgrade. Or ones where the WF dev is heavily involved so even if they don't release they know about the release. 2) Other projects that are only direct deps of the WF/WF Core code bases. 3) Transitive deps. Posting an automated PR is most useful for the #2 case. For the #3 case we'd need to go to the WF dev responsible for integrating whatever project(s) is pulling it in, say RESTEasy or CXF and get them to confirm that the upgrade is ok.

> > I'm glad to see the discussion of configurable rules, as that's quite > important.  I wouldn't like to see anything proposed except micro version > updates or less than micro. No minors. If that's inappropriate for some > component then that could be adjusted for that one, but the default should be > micros only. Agree. > > I also think some sort of time delay is appropriate, probably at least a week. > Having an automated system race with the humans working on WildFly would be > annoying. Github already notifies us of possible upgrades to components with CVEs. I also think long interval is better. Even maybe rather than running on regular intervals it could be triggered manually by RC after every EAP release or during some part of the release cycle. Tomas > > Best regards, > Brian > > > On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)redhat.com <mailto:thofman@redhat.com> > <mailto:thofman@redhat.com <mailto:thofman@redhat.com>>> wrote: > >     Hello, > >     would the Wildfly team be interested in (or opposed to) receiving component >     upgrade PRs, which would be created automatically when a new component version >     is released? (I'm talking about new micro/SP versions, depending on the >     component, i.e. version that could be reasonably expected to be suitable for >     consumption, without issues like breaking API changes etc.) > >     I'm working on a tool [1], which is able to provide these PRs. > >     The tool scans given project for dependencies, and then looks at what versions >     of those dependencies are available in Maven Central and possibly other >     repositories. I can configure rules for each dependency, that specify what >     versions should be considered viable for upgrading (e.g. for >     "org.picketlink:*" >     we would only offer new "SP" builds in the same micro, for most of the other >     dependencies we would only offer new micros, and some artifacts would perhaps >     be blacklisted). Example of this configuration is here [2]. > >     Advantages that I believe could be gained from this: > >     * It would bring us an advantage of having new component micros tested soon in >     Wildfly, and therefore having more confidence when we need to do the same >     upgrades in EAP. > >     * It would also help in preventing EAP running ahead of Wildfly in component >     versions, which happens occasionally. EAP release coordinator usually spots >     this problem and creates missing PR in Wildfly, but it's a manual check and >     therefore a small risk remains. > >     * It would ensure Wildfly is consuming latest component fixes. > >     You can review PRs generated last week in my fork of Wildfly [3]. > >     It's a work in progress, I expect the tool and it's configuration would evolve >     according to experiences we would get from using it... > >     What do you think? > >     [1] https://github.com/TomasHofman/maven-dependency-updater/ >     [2] > https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... >     [3] https://github.com/TomasHofman/wildfly/pulls > >     -- >     Tomas Hofman >     Software Engineer, JBoss SET >     Red Hat >     _______________________________________________ >     wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat -- Tomas Hofman Software Engineer, JBoss SET Red Hat -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat

Nice idea.  Thomas, have you tried adopting an already established format for the allowed versions?  Either Maven ranges or the Gemfiles (Ruby) version specs? Fernando On 2019-09-02 3:44 a.m., Tomas Hofman wrote: > Hello, > > would the Wildfly team be interested in (or opposed to) receiving component > upgrade PRs, which would be created automatically when a new component version > is released? (I'm talking about new micro/SP versions, depending on the > component, i.e. version that could be reasonably expected to be suitable for > consumption, without issues like breaking API changes etc.) > > I'm working on a tool [1], which is able to provide these PRs. > > The tool scans given project for dependencies, and then looks at what versions > of those dependencies are available in Maven Central and possibly other > repositories. I can configure rules for each dependency, that specify what > versions should be considered viable for upgrading (e.g. for "org.picketlink:*" > we would only offer new "SP" builds in the same micro, for most of the other > dependencies we would only offer new micros, and some artifacts would perhaps > be blacklisted). Example of this configuration is here [2]. > > Advantages that I believe could be gained from this: > > * It would bring us an advantage of having new component micros tested soon in > Wildfly, and therefore having more confidence when we need to do the same > upgrades in EAP. > > * It would also help in preventing EAP running ahead of Wildfly in component > versions, which happens occasionally. EAP release coordinator usually spots > this problem and creates missing PR in Wildfly, but it's a manual check and > therefore a small risk remains. > > * It would ensure Wildfly is consuming latest component fixes. > > You can review PRs generated last week in my fork of Wildfly [3]. > > It's a work in progress, I expect the tool and it's configuration would evolve > according to experiences we would get from using it... > > What do you think? > > [1] https://github.com/TomasHofman/maven-dependency-updater/ > [2] > https://github.com/jboss-set/dependency-alignment-configs/blob/master/wil... > [3] https://github.com/TomasHofman/wildfly/pulls >