Our elytron-web repo would also be interesting - we don't spend a lot of time in that repo so reminders things need an update could help there.


On Tue, Sep 3, 2019 at 2:53 PM Tomas Hofman <thofman@redhat.com> wrote:
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@redhat.com
> <mailto:cdewolf@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@redhat.com
>>     <mailto:thofman@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@redhat.com
>>         <mailto:thofman@redhat.com>
>>         > <mailto:thofman@redhat.com <mailto:thofman@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@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>         <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@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@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>     _______________________________________________
>>     wildfly-dev mailing list
>>     wildfly-dev@lists.jboss.org  <mailto:wildfly-dev@lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat