[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Darran Lofthouse
darran.lofthouse at jboss.com
Tue Sep 3 09:54:57 EDT 2019
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> 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>> 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>> 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>>>
> 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>>
> >> > 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
> >
> >> 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>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
> --
> Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190903/0f585d99/attachment.html
More information about the wildfly-dev
mailing list