[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Darran Lofthouse
darran.lofthouse at jboss.com
Tue Sep 3 05:31:56 EDT 2019
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> 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> 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>> 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>
>> > 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
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190903/97cb1c39/attachment.html
More information about the wildfly-dev
mailing list