[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?

Tomas Hofman thofman at redhat.com
Tue Sep 3 10:05:28 EDT 2019


For 1.x branch:

Generated at 16:03:57 2019-09-03

io.undertow:undertow-core:2.0.25.Final -> 2.0.26.Final
io.undertow:undertow-servlet:2.0.25.Final -> 2.0.26.Final
org.apache.httpcomponents:httpclient:4.5.6 -> 4.5.9
org.apache.httpcomponents:httpcore:4.4.5 -> 4.4.11
org.infinispan:infinispan-core:9.3.3.Final -> 9.3.6.Final
org.wildfly.common:wildfly-common:1.5.1.Final -> 1.5.2.Final


On 03/09/2019 15:54, Darran Lofthouse wrote:
> 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 at redhat.com 
> <mailto:thofman at 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 at redhat.com
>     <mailto:cdewolf at redhat.com>
>      > <mailto:cdewolf at redhat.com <mailto:cdewolf at 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 at redhat.com
>     <mailto:thofman at redhat.com>
>      >>     <mailto:thofman at redhat.com <mailto:thofman at 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 at redhat.com <mailto:thofman at redhat.com>
>      >>         <mailto:thofman at redhat.com <mailto:thofman at redhat.com>>
>      >>         > <mailto:thofman at redhat.com <mailto:thofman at redhat.com>
>     <mailto:thofman at redhat.com <mailto:thofman at 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/wildfly-18-minimal.json#L44
>      >>         >     [3] https://github.com/TomasHofman/wildfly/pulls
>      >>         >
>      >>         >     --
>      >>         >     Tomas Hofman
>      >>         >     Software Engineer, JBoss SET
>      >>         >     Red Hat
>      >>         >     _______________________________________________
>      >>         >     wildfly-dev mailing list
>      >>         > wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org> <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org>>
>      >>         <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org> <mailto:wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto:wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>>
>      >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>
>      >>
>      >>     _______________________________________________
>      >>     wildfly-dev mailing list
>      >> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org> 
>     <mailto:wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>>
>      >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
> 
>     -- 
>     Tomas Hofman
>     Software Engineer, JBoss SET
>     Red Hat
> 

-- 
Tomas Hofman
Software Engineer, JBoss SET
Red Hat


More information about the wildfly-dev mailing list