3:29 p.m.
Hi Jeff,
I did the last few updates of the archetypes, so I am used to the
process to check all plugins for new versions ;-). I am also willing to
continue doing this. Most of the time, the hard stuff was to find
someone who could do a release of the archetype ;-). This was also the
reason why I did not do my standard upgrade check for all plugins last
time - Brian release the archetypes for 28, did the update to 29 himself
and released them.
The dependabot pull requests won't not help me, because I don't have the
privileges to merge them. In order to test whether they work (when
preparing for a new WildFly version), I would have to apply them to my
local project (in combination with the next WildFly update), do my test
script and then revert them again - or tell the guy who updates my pull
request that my change also contains the plugin updates and that the
dependabot changes can be discarded.
If the Ear archetype does not receive those update notifications, this
is dangerous - here they would have to applied by a human - that's
dangerous to forget them.
An automated test for each archetype would be nice, but as far as I
understand you, this would only work for managed servers. I also have
test scripts for remote servers, as the archetypes contain a profile for
them. The subsystem archetype cannot be tested as managed server as far
as I know. So it seems automated tests would not provide the same
coverage that my manual tests do.
My current opinion is that the dependabot or automated don't not help
me, just make my life harder ;-)
Best regards
Wolfgang
Am 10.08.23 um 09:13 schrieb Jeff Mesnil:
> Hi,
>
>> On 9 Aug 2023, at 22:42, Wolfgang Knauf <wolfgang.knauf(a)gmx.de> wrote:
>>
>> E.g. https://github.com/wildfly/wildfly-archetypes/pull/34:
>> maven-war-plugin is updated to 3.4.0 in the webapp archetype, but not in
>> the ear archetype.
> Dependabot is failing to update the EAR archetype and is reporting the error at
> https://github.com/wildfly/wildfly-archetypes/network/updates/706959277
>
> The issue is due to the velocity templating and the mismatch between the name of the
modules in the pom.xml (eg <module>${rootArtifactId}-ejb</module>) and the
actual name of the directory (__rootArtifactId__ejb).
>
> I’m not sure there is much we can do here to make dependabot works...
>
>> I consider this automatic update a bit dangerous, as there seems to be
>> no further validation.
> Just to be clear, the PRs opened by dependabot are not automatically merged.
> They are automatically opened. It has the big advantage that we don’t have to figure
out if the component is up to date when we do a release , we have the dependabot PRs that
tells us what *could* be updated.
>
>> Is there a mechanism to create a project from
>> each archetype and deploy it to WildFly?
> As far as I can tell, Maven archetype:integration-test has a postBuildHookScript[1]
that might serve this purpose.
> It could download WildFly, start it, run mvn wildfly:deploy on the generated project
and a curl to verify that the deployment is working.
>
> On that topic, I’ve setup a CI to test the archetypes at
https://github.com/wildfly/wildfly-archetypes/actions/workflows/maven.yml.
> We could definitively download the latest version of WildFly as a steps in the CI and
make a JBOSS_HOME variable available.
> With this setup, your testing script at [2] could be run by the CI.
>
>> If this is not happening in the future, a broken archetype might be released.
> Again, I was not clear enough when I said « automatic updates ». I only automated the
creation of the dependency updates. They are not merged automatically and this is not
something I envision anyway. I’m just a lazy developer that wants tools to tell me what
*could* be updated instead of having to look at 10 different plugins and see which ones
are new.
>
> Thanks for the feedback,
>
> Best regards,
> Jeff
>
> [1]
https://maven.apache.org/archetype/maven-archetype-plugin/integration-tes...
> [2]
https://github.com/wildfly/wildfly-archetypes/blob/main/wildfly-jakartaee...
> --
> Jeff Mesnil
> Engineer @ Red Hat JBoss EAP
> http://jmesnil.net/
>