<div dir="ltr">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.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 3, 2019 at 2:53 PM Tomas Hofman <<a href="mailto:thofman@redhat.com">thofman@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Running it on wildfly-elytron 1.x branch gives quite brief report:<br>
<br>
Generated at 15:42:49 2019-09-03<br>
<br>
org.apache.commons:commons-lang3:3.8 -> 3.8.1<br>
org.jboss.spec.javax.json:jboss-json-api_1.0_spec:1.0.0.Final -> 1.0.1.Final<br>
org.jboss.spec.javax.security.jacc:jboss-jacc-api_1.5_spec:1.0.1.Final -> <br>
1.0.2.Final<br>
org.wildfly.common:wildfly-common:1.5.1.Final -> 1.5.2.Final<br>
<br>
<br>
Are you interested in any other component?<br>
<br>
<br>
On 03/09/2019 11:31, Darran Lofthouse wrote:<br>
> That would be really useful as we should be coordinating these via the <br>
> component leads rather than just at the very end.<br>
> <br>
> On Tue, Sep 3, 2019 at 10:23 AM Carlo de Wolf <<a href="mailto:cdewolf@redhat.com" target="_blank">cdewolf@redhat.com</a> <br>
> <mailto:<a href="mailto:cdewolf@redhat.com" target="_blank">cdewolf@redhat.com</a>>> wrote:<br>
> <br>
> The tool is not WildFly specific, so it should be able to run on any project.<br>
> <br>
> Carlo<br>
> <br>
> On 03-09-19 11:01, Darran Lofthouse wrote:<br>
>> An e-mail report would be really good, component leads may want to apply<br>
>> the update to their own projects first to double check.<br>
>><br>
>> On Tue, Sep 3, 2019 at 9:55 AM Tomas Hofman <<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a><br>
>> <mailto:<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a>>> wrote:<br>
>><br>
>><br>
>><br>
>> On 02/09/2019 17:55, Brian Stansberry wrote:<br>
>> > Hi Tomas,<br>
>> ><br>
>> > Can this generate emails to this list instead of PRs? Processing<br>
>> PRs is<br>
>> > expensive, both in terms of burden on our somewhat overburdened CI<br>
>> and in terms<br>
>> > of forcing mergers to deal with a PR queue. I'm not opposed to<br>
>> ending up<br>
>> > getting PRs but I'd like to see any system producing acceptable<br>
>> inputs before<br>
>> > we let it at the PR queue.<br>
>><br>
>> That's a good idea, we could definitely start with an email report.<br>
>> Would give<br>
>> us chance to get the configuration in shape without cluttering the PR<br>
>> queue. I<br>
>> will post it.<br>
>><br>
>> I was thinking about what is the most easily consumable form to<br>
>> deliver this.<br>
>> If we do manual review first, than perhaps single large PRs is better<br>
>> than<br>
>> separate PRs for each upgrade, to minimize CI burden and generate<br>
>> less noise<br>
>> for PR reviewers.<br>
>><br>
>> ><br>
>> > I'm glad to see the discussion of configurable rules, as that's quite<br>
>> > important. I wouldn't like to see anything proposed except micro<br>
>> version<br>
>> > updates or less than micro. No minors. If that's inappropriate for<br>
>> some<br>
>> > component then that could be adjusted for that one, but the default<br>
>> should be<br>
>> > micros only.<br>
>><br>
>> Agree.<br>
>><br>
>> ><br>
>> > I also think some sort of time delay is appropriate, probably at<br>
>> least a week.<br>
>> > Having an automated system race with the humans working on WildFly<br>
>> would be<br>
>> > annoying. Github already notifies us of possible upgrades to<br>
>> components with CVEs.<br>
>><br>
>> I also think long interval is better. Even maybe rather than running<br>
>> on regular<br>
>> intervals it could be triggered manually by RC after every EAP<br>
>> release or<br>
>> during some part of the release cycle.<br>
>><br>
>><br>
>> Tomas<br>
>><br>
>> ><br>
>> > Best regards,<br>
>> > Brian<br>
>> ><br>
>> ><br>
>> > On Mon, Sep 2, 2019 at 2:52 AM Tomas Hofman <<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a><br>
>> <mailto:<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a>><br>
>> > <mailto:<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a> <mailto:<a href="mailto:thofman@redhat.com" target="_blank">thofman@redhat.com</a>>>> wrote:<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> > would the Wildfly team be interested in (or opposed to)<br>
>> receiving component<br>
>> > upgrade PRs, which would be created automatically when a new<br>
>> component version<br>
>> > is released? (I'm talking about new micro/SP versions,<br>
>> depending on the<br>
>> > component, i.e. version that could be reasonably expected to be<br>
>> suitable for<br>
>> > consumption, without issues like breaking API changes etc.)<br>
>> ><br>
>> > I'm working on a tool [1], which is able to provide these PRs.<br>
>> ><br>
>> > The tool scans given project for dependencies, and then looks<br>
>> at what versions<br>
>> > of those dependencies are available in Maven Central and<br>
>> possibly other<br>
>> > repositories. I can configure rules for each dependency, that<br>
>> specify what<br>
>> > versions should be considered viable for upgrading (e.g. for<br>
>> > "org.picketlink:*"<br>
>> > we would only offer new "SP" builds in the same micro, for most<br>
>> of the other<br>
>> > dependencies we would only offer new micros, and some artifacts<br>
>> would perhaps<br>
>> > be blacklisted). Example of this configuration is here [2].<br>
>> ><br>
>> > Advantages that I believe could be gained from this:<br>
>> ><br>
>> > * It would bring us an advantage of having new component micros<br>
>> tested soon in<br>
>> > Wildfly, and therefore having more confidence when we need to<br>
>> do the same<br>
>> > upgrades in EAP.<br>
>> ><br>
>> > * It would also help in preventing EAP running ahead of Wildfly<br>
>> in component<br>
>> > versions, which happens occasionally. EAP release coordinator<br>
>> usually spots<br>
>> > this problem and creates missing PR in Wildfly, but it's a<br>
>> manual check and<br>
>> > therefore a small risk remains.<br>
>> ><br>
>> > * It would ensure Wildfly is consuming latest component fixes.<br>
>> ><br>
>> > You can review PRs generated last week in my fork of Wildfly [3].<br>
>> ><br>
>> > It's a work in progress, I expect the tool and it's<br>
>> configuration would evolve<br>
>> > according to experiences we would get from using it...<br>
>> ><br>
>> > What do you think?<br>
>> ><br>
>> > [1] <a href="https://github.com/TomasHofman/maven-dependency-updater/" rel="noreferrer" target="_blank">https://github.com/TomasHofman/maven-dependency-updater/</a><br>
>> > [2]<br>
>> ><br>
>> <a href="https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44" rel="noreferrer" target="_blank">https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44</a><br>
>> > [3] <a href="https://github.com/TomasHofman/wildfly/pulls" rel="noreferrer" target="_blank">https://github.com/TomasHofman/wildfly/pulls</a><br>
>> ><br>
>> > --<br>
>> > Tomas Hofman<br>
>> > Software Engineer, JBoss SET<br>
>> > Red Hat<br>
>> > _______________________________________________<br>
>> > wildfly-dev mailing list<br>
>> > <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
>> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>>><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Brian Stansberry<br>
>> > Manager, Senior Principal Software Engineer<br>
>> > Red Hat<br>
>><br>
>> -- <br>
>> Tomas Hofman<br>
>> Software Engineer, JBoss SET<br>
>> Red Hat<br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> <br>
<br>
-- <br>
Tomas Hofman<br>
Software Engineer, JBoss SET<br>
Red Hat<br>
</blockquote></div>