[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Tomas Hofman
thofman at redhat.com
Mon Sep 9 10:37:45 EDT 2019
On 03/09/2019 20:45, Brian Stansberry wrote:
>
> 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.
>
>
> Looking at the first report I think we've got a way to go before we get to PRs. :)
>
> In general I don't think PRs with a lot of upgrades will be useful, as they are
> not actionable unless 100% of the upgrades are valid. OTOH I can see how
> having 20 PRs for different CXF components would be annoying and would drown CI
> for some hours.
>
> Something slick might be for the tool to understand the version property
> strings and aggregate based on that.
This is in fact (partially) solved problem during PR creation - I collect SHA
digests of pom.xml after each component upgrade and test if the same digest has
been collected before. If so, that means that the change for given component
upgrade has already been performed during some previous component upgrade and
PR creation is skipped.
I can use the same technique when generating an email report.
I just need to make this digest log permanent, now it only exists for the
duration of single execution of the tool.
>
> I see three categories of upgrades:
>
> 1) Projects that the main WF devs control, so we're doing the release and the
> upgrade. Or ones where the WF dev is heavily involved so even if they don't
> release they know about the release.
> 2) Other projects that are only direct deps of the WF/WF Core code bases.
> 3) Transitive deps.
>
> Posting an automated PR is most useful for the #2 case. For the #3 case we'd
> need to go to the WF dev responsible for integrating whatever project(s) is
> pulling it in, say RESTEasy or CXF and get them to confirm that the upgrade is ok.
Agree, category 1) could be blacklisted straight away. Will try to do that - we
probably don't need to see those in email reports either.
Categories 2) and 3) are hard to distinguish, because I think Wildfly lists
practically all third-party deps as it's own deps.
We could devise some easy way to blacklist dependency when an unwanted PR is
generated, e.g. by posting a "Ignore this component" comment in the PR or
something like that.
>
>
> >
> > 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
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
More information about the wildfly-dev
mailing list