Hi, it seems dependabot updates e.g. maven plugins only in one archetype, but not in all? 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. Or did this not happen, because dependabot checks each archetype project, and after five pull requests it does not continue? Up to now, I did the plugin updates when updating the WildFly version ;-). I consider this automatic update a bit dangerous, as there seems to be no further validation. Is there a mechanism to create a project from each archetype and deploy it to WildFly? I created testing scripts and run those tests after each WildFly update. If this is not happening in the future, a broken archetype might be released. Best regards Wolfgang Am 09.08.23 um 14:34 schrieb Jeff Mesnil: > Hi, > >> On 9 Aug 2023, at 12:04, Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >> >> Hi, >> >> I’ve been looking at our archetypes at https://github.com/wildfly/wildfly-archetypes as we could leverage them to improve the user experience of getting started with WildFly (see my previous mail). >> >> The project could benefit from enabling dependabot updates: > > Done. Dependabot has started to open PRs to updates the archetypes pom.xml as well as the generated projects’s pom.xml: > > https://github.com/wildfly/wildfly-archetypes/pulls?q=is%3Apr+label%3Adep... > >> I’ll also take the opportunity to move its default branch to `main` instead of `master` before applying these changes and create a GitHub action to get minimal CI for this project. > The default branch is now `main`. The usual instructions to change that in your local forks apply: > > —8<— > git branch -m master main > git fetch origin > git branch -u origin/main main > git remote set-head origin -a > —8<— > > I’ve enabled a GitHub action to « mvn verify » the archetypes. This means that their tests (which generates projects) are also testing component updates to the generated projects’s pom.xml: > > https://github.com/wildfly/wildfly-archetypes/actions/workflows/maven.yml > > Best regards, > Jeff > > -- > Jeff Mesnil > Engineer @ Red Hat JBoss EAP > http://jmesnil.net/ > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

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&gt; 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/ >

Hi Jeff, just a short feedback - your commit looks good to me, but I don't have any knowledge about Github workflows, so I cannot comment about the details ;-). Keep on working on it! Best regards Wolfgang Am 16.08.23 um 14:40 schrieb Jeff Mesnil: > Hi Wolfgang, > > Starting with your comment at the bottom: > >> My current opinion is that the dependabot or automated don't not help >> me, just make my life harder ;-) > That’s definitely not my goal, quite the opposite :) > > I want to streamline and delegate to CI the maintenance cost of the archetypes (keeping up with dependencies, testing that nothing is broken, etc.). > > I think we can achieve that and make your life (or any contributor) easier :) > > As an example, I’ve opened a PR that runs your tests for all 3 archetypes in managed and remote setup: > > https://github.com/wildfly/wildfly-archetypes/pull/36 > > With this CI in place, any changes to the archetypes would be checked as you are doing now manually afaict. You can see a summary of all testing at https://github.com/wildfly/wildfly-archetypes/actions/runs/5878713295 > > On 10 Aug 2023, at 22:29, Wolfgang Knauf <wolfgang.knauf(a)gmx.de&gt; wrote: >> 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 ;-). > I would definitely be happy to help on that front if I’m confident about the code quality whenever we need a release. > >> 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. > With the CI above, we could update dependencies for the subsystem and war whenever their dependencies are updated. > >> 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. > That’s the only part that I’ve not been able to automate. > Someone would have to check the deps at https://github.com/wildfly/wildfly-archetypes/blob/554c1aa785c2ffd1054f7d... and make sure they are aligned with the web app archetype at https://github.com/wildfly/wildfly-archetypes/blob/554c1aa785c2ffd1054f7d... (+ the ear and ejb plugin) > > >> 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. > I think they do. Did I miss a coverage from them? Could you please review https://github.com/wildfly/wildfly-archetypes/pull/36? > > Best regards, > Jeff >