[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Carlo de Wolf
cdewolf at redhat.com
Tue Sep 3 05:23:10 EDT 2019
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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190903/eaa1f04d/attachment-0001.html
More information about the wildfly-dev
mailing list