10:55 a.m.
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.
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.
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.
Best regards,
Brian
On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <thofman(a)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/wil...
[3] https://github.com/TomasHofman/wildfly/pulls
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat