Automate keeping Wildfly dependencies up-to-date?
by Tomas Hofman
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/wil...
[3] https://github.com/TomasHofman/wildfly/pulls
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
5 years, 4 months
Wildfly-core - component upgrades report
by Tomas Hofman
Generated at 15:55:39 2019-09-03
com.jcraft:jsch:0.1.54 -> 0.1.55
com.jcraft:jzlib:1.1.1 -> 1.1.3
javax.json:javax.json-api:1.1.2 -> 1.1.4
org.apache.httpcomponents:httpclient:4.5.4 -> 4.5.9
org.apache.httpcomponents:httpcore:4.4.5 -> 4.4.11
org.apache.httpcomponents:httpcore-nio:4.4.5 -> 4.4.11
org.apache.httpcomponents:httpmime:4.5.4 -> 4.5.9
org.apache.maven:maven-resolver-provider:3.5.0 -> 3.5.4
org.apache.maven.resolver:maven-resolver-api:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-connector-basic:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-impl:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-spi:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-transport-file:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-transport-http:1.1.0 -> 1.1.1
org.apache.maven.resolver:maven-resolver-util:1.1.0 -> 1.1.1
org.codehaus.plexus:plexus-utils:3.1.0 -> 3.1.1
org.glassfish:javax.json:1.1.2 -> 1.1.4
org.jboss.slf4j:slf4j-jboss-logmanager:1.0.3.GA -> 1.0.4.GA
org.slf4j:jcl-over-slf4j:1.7.22.jbossorg-1 -> 1.7.28
org.slf4j:slf4j-api:1.7.22.jbossorg-1 -> 1.7.28
org.slf4j:slf4j-ext:1.7.22.jbossorg-1 -> 1.7.28
org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.2.10.Final ->
1.2.11.Final
org.wildfly.common:wildfly-common:1.5.1.Final -> 1.5.2.Final
org.wildfly.openssl:wildfly-openssl-linux-i386:1.0.7.Final -> 1.0.8.Final
org.wildfly.openssl:wildfly-openssl-linux-x86_64:1.0.7.Final -> 1.0.8.Final
org.wildfly.openssl:wildfly-openssl-macosx-x86_64:1.0.7.Final -> 1.0.8.Final
org.wildfly.openssl:wildfly-openssl-windows-i386:1.0.7.Final -> 1.0.8.Final
org.wildfly.openssl:wildfly-openssl-windows-x86_64:1.0.7.Final -> 1.0.8.Final
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
5 years, 4 months
Fwd: Re: Automate keeping Wildfly dependencies up-to-date?
by Tomas Hofman
Reposting to the list.
-------- Forwarded Message --------
Subject: Re: [wildfly-dev] Automate keeping Wildfly dependencies up-to-date?
Date: Mon, 2 Sep 2019 17:02:05 +0200
From: Tomas Hofman <thofman(a)redhat.com>
To: Rostislav Svoboda <rsvoboda(a)redhat.com>
In general - probably - yes, although I haven't investigated details. I'm
instead building on top of PME (Project Newcastle) and Maven Versions Plugin,
so there is code reuse too.
On 02/09/2019 16:24, Rostislav Svoboda wrote:
>
>> On 2 Sep 2019, at 15:44, Tomas Hofman <thofman(a)redhat.com
>> <mailto:thofman@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 tohttps://github.com/marketplace/dependabot-preview
>>> What are the main differences ?
>>> Rostislav
>>>> On 2 Sep 2019, at 09:44, Tomas Hofman <thofman(a)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/wil...
>>>> [3] https://github.com/TomasHofman/wildfly/pulls
>>>>
>>>> --
>>>> Tomas Hofman
>>>> Software Engineer, JBoss SET
>>>> Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Tomas Hofman
>> Software Engineer, JBoss SET
>> Red Hat
>
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
5 years, 4 months
