[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Tomas Hofman
thofman at redhat.com
Tue Sep 3 09:53:43 EDT 2019
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
More information about the wildfly-dev
mailing list