[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?

[Rostislav Svoboda]

> On 2 Sep 2019, at 15:44, Tomas Hofman <thofman at redhat.com> wrote:
> 
> Yes, to me the main difference is that dependabot doesn't allow to configure per component "rules" limiting when you want to upgrade.

Would it be possible to extend dependabot instead of developing&maintaining own solution?

> 
> E.g. I want to be able to say: for artifacts with G:A "org.picketlink:*", only upgrade if there's a higher version starting with "2.5.5" and having qualifier that matches regex "SP-\\d".
> 
> Tomas
> 
> On 02/09/2019 11:45, Rostislav Svoboda wrote:
>> This tools sounds similar to https://github.com/marketplace/dependabot-preview <https://github.com/marketplace/dependabot-preview>
>> What are the main differences ?
>> Rostislav
>>> On 2 Sep 2019, at 09:44, 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
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> Tomas Hofman
> Software Engineer, JBoss SET
> Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190902/6e441381/attachment.html