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

[Carlo de Wolf]

In similar vain dependabot tries to aggressively upgrade without 
understanding a proper versioning scheme. It only understands major, 
minor & patch level.

My initial encounter didn't show good results: 
https://github.com/wolfc/jboss-eap7/pulls
At that point you're stuck into a mode of "teaching" dependabot what you 
really want without any form of control.

Being able to do authoritative configuration upfront is a must to retain 
sanity. :-)

Carlo

On 02-09-19 11:58, Ladislav Thon wrote:
>
> I took a quick look at the README of Tomas's project and the main 
> difference seems to be the opt-in approach, as opposed to Dependabot's 
> opt-out approach. Dependabot attempts to update everything, and you 
> have to opt out of certain dependencies (by commenting in pull 
> requests!). If you have multiple repositories with similar needs, you 
> have to opt out for each repository again and again. If I understand 
> Tomas's project correctly, you can define configuration upfront, and 
> it won't touch dependencies that are not configured.
>
> Tomas, please correct me if I'm wrong here :-)
>
> LT
>
> On 02. 09. 19 11:45, Rostislav Svoboda wrote:
>> This tools sounds similar to 
>> 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>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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