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

[Ladislav Thon]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190902/436ff14f/attachment.html