On 26 Jul 2023, at 19:32, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: But James Perkins has pointed out that such JIRA tracking is kind of overkill for non-production dependencies (e.g. test and build deps) and I agree.

The other thing I care about a lot is being able to grep the git log for commits related to a JIRA. That would of course be lost for non-production upgrades with no JIRA. Oh well. Also though dependabot wouldn't put our JIRA in its commit messages. But for PRs where we file a JIRA we can require human edit of the dependabot PR title to reference the JIRA. That will result in the JIRA appearing in the log via the merge commit Github generates. That solves the git log use case adequately enough IMO.

On Thu, Jul 27, 2023 at 1:56 AM Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: > Hi Brian, > > > On 26 Jul 2023, at 19:32, Brian Stansberry <brian.stansberry(a)redhat.com&gt; > wrote: > > But James Perkins has pointed out that such JIRA tracking is kind of > overkill for non-production dependencies (e.g. test and build deps) and I > agree. > > > +1 > > > The other thing I care about a lot is being able to grep the git log > for commits related to a JIRA. That would of course be lost for > non-production upgrades with no JIRA. Oh well. Also though dependabot > wouldn't put our JIRA in its commit messages. But for PRs where we file a > JIRA we can require human edit of the dependabot PR title to reference the > JIRA. That will result in the JIRA appearing in the log via the merge > commit Github generates. That solves the git log use case adequately enough > IMO. > > > As an example, we did experiment with this approach in WildFly Core with > some PR opened by Dependabot: > > https://github.com/wildfly/wildfly-core/pull/4937 > > which resulted in the merge commit: > > > https://github.com/wildfly/wildfly-core/commit/50eafdb9ec87d9d0ad94288e86... +1. People may notice I sometimes edit PR titles a bit before merging, or request title changes during code review. I do this to tweak the merge commit message, usually to add a missing JIRA ref. > > Best regards, > jeff > > -- > Jeff Mesnil > Engineer @ Red Hat JBoss EAP > http://jmesnil.net/ > > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His _______________________________________________ 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...

And after a little testing, we can force push the dependabot branches :) - https://github.com/xstefank/wildfly/pull/67. So the wildfly-bot can adjust dynamically also the commit message. So just let me know what would be the preferred way of doing this and we can get it done in wildfly-bot.

Cheers, Martin Stefanko Principal Software Engineer Middleware Runtimes Sustaining Engineering Team Red Hat On Thu, Jul 27, 2023 at 5:27 PM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > Just a few ideas. > > As mentioned in the other thread, wildfly-bot could act as "dependabot" > by for instance taking the upgrade report sent to this mailing list and > creating PRs with correct format based on it. The question is if the > dependabot would perform better or if the report is sufficient in terms of > what needs to be upgraded. > > Bot can also create JIRA automatically. > > Bot can also easily change whatever can be changed in the PR created by > the dependabot automatically. So there is no need for manual interventions. > Also, if we can set up potentially automatic merging of PRs if all > workflows pass (I know, just a crazy idea). > > Cheers, > Martin Stefanko > > Principal Software Engineer > Middleware Runtimes Sustaining Engineering Team > Red Hat > > > On Thu, Jul 27, 2023 at 4:37 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> >> >> On Thu, Jul 27, 2023 at 1:56 AM Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >> >>> Hi Brian, >>> >>> > On 26 Jul 2023, at 19:32, Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> > But James Perkins has pointed out that such JIRA tracking is kind of >>> overkill for non-production dependencies (e.g. test and build deps) and I >>> agree. >>> >>> >>> +1 >>> >>> > The other thing I care about a lot is being able to grep the git log >>> for commits related to a JIRA. That would of course be lost for >>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>> JIRA we can require human edit of the dependabot PR title to reference the >>> JIRA. That will result in the JIRA appearing in the log via the merge >>> commit Github generates. That solves the git log use case adequately enough >>> IMO. >>> >>> >>> As an example, we did experiment with this approach in WildFly Core >>> with some PR opened by Dependabot: >>> >>> https://github.com/wildfly/wildfly-core/pull/4937 >>> >>> which resulted in the merge commit: >>> >>> >>> https://github.com/wildfly/wildfly-core/commit/50eafdb9ec87d9d0ad94288e86... >> >> >> +1. >> >> People may notice I sometimes edit PR titles a bit before merging, or >> request title changes during code review. I do this to tweak the merge >> commit message, usually to add a missing JIRA ref. >> >> >>> >>> Best regards, >>> jeff >>> >>> -- >>> Jeff Mesnil >>> Engineer @ Red Hat JBoss EAP >>> http://jmesnil.net/ >>> >>> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> _______________________________________________ >> 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... >> > _______________________________________________ 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...

On Thu, Jul 27, 2023 at 10:39 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > And after a little testing, we can force push the dependabot branches :) > - https://github.com/xstefank/wildfly/pull/67. So the wildfly-bot can > adjust dynamically also the commit message. So just let me know what would > be the preferred way of doing this and we can get it done in wildfly-bot. > That's very cool, but my instinct on this is to defer it a bit more to the future so we can experiment more and think about side effects. More inline below. > Cheers, > Martin Stefanko > > Principal Software Engineer > Middleware Runtimes Sustaining Engineering Team > Red Hat > > > > On Thu, Jul 27, 2023 at 5:27 PM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> Just a few ideas. >> >> As mentioned in the other thread, wildfly-bot could act as "dependabot" >> by for instance taking the upgrade report sent to this mailing list and >> creating PRs with correct format based on it. The question is if the >> dependabot would perform better or if the report is sufficient in terms of >> what needs to be upgraded. >> >> Bot can also create JIRA automatically. >> >> Bot can also easily change whatever can be changed in the PR created by >> the dependabot automatically. So there is no need for manual interventions. >> > This sounds great. As noted above I feel initially cautious about tweaking the update commit itself, but being able to get automate JIRA filing and adding the JIRA # to the PR title and the JIRA link to the PR description sounds great. > Also, if we can set up potentially automatic merging of PRs if all >> workflows pass (I know, just a crazy idea). >> > You're a wild man. :) My impression is we're pretty good about getting micro component upgrades merged pretty quickly once SMEs have approved them. I'm interested to know if people feel differently. It's the approval that can tend to take time, and often that's due to the need to validate updates against external testsuites, i.e. the project testsuites for the larger components that use the upgrade candidate. We also have windows around releases where we want strict control over what's being merged. >> Cheers, >> Martin Stefanko >> >> Principal Software Engineer >> Middleware Runtimes Sustaining Engineering Team >> Red Hat >> >> >> On Thu, Jul 27, 2023 at 4:37 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Thu, Jul 27, 2023 at 1:56 AM Jeff Mesnil <jmesnil(a)redhat.com&gt; wrote: >>> >>>> Hi Brian, >>>> >>>> > On 26 Jul 2023, at 19:32, Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> > But James Perkins has pointed out that such JIRA tracking is kind of >>>> overkill for non-production dependencies (e.g. test and build deps) and I >>>> agree. >>>> >>>> >>>> +1 >>>> >>>> > The other thing I care about a lot is being able to grep the git log >>>> for commits related to a JIRA. That would of course be lost for >>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>> JIRA we can require human edit of the dependabot PR title to reference the >>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>> commit Github generates. That solves the git log use case adequately enough >>>> IMO. >>>> >>>> >>>> As an example, we did experiment with this approach in WildFly Core >>>> with some PR opened by Dependabot: >>>> >>>> https://github.com/wildfly/wildfly-core/pull/4937 >>>> >>>> which resulted in the merge commit: >>>> >>>> >>>> https://github.com/wildfly/wildfly-core/commit/50eafdb9ec87d9d0ad94288e86... >>> >>> >>> +1. >>> >>> People may notice I sometimes edit PR titles a bit before merging, or >>> request title changes during code review. I do this to tweak the merge >>> commit message, usually to add a missing JIRA ref. >>> >>> >>>> >>>> Best regards, >>>> jeff >>>> >>>> -- >>>> Jeff Mesnil >>>> Engineer @ Red Hat JBoss EAP >>>> http://jmesnil.net/ >>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> He/Him/His >>> _______________________________________________ >>> 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... >>> >> -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

Occasionally we've thought about turning on dependabot for the main WildFly repo, and a couple current discussions (see [1] and [2]) relate to that, so it seems a good time to discuss further and perhaps take action. My main concern with dependabot is it doesn't integrate with JIRA. JIRA is really important to how we're able to keep a handle on a project as complex as WildFly. And I think it's important to track component upgrades in JIRA so our users can keep an eye on what we're providing. Particularly important in the world of ubiquitous CVE scanners. But James Perkins has pointed out that such JIRA tracking is kind of overkill for non-production dependencies (e.g. test and build deps) and I agree. So, how about we turn on dependabot and require a JIRA to be filed and linked to the PR if the proposed upgrade is production code dep? For non-production deps a JIRA would be optional. The other thing I care about a lot is being able to grep the git log for commits related to a JIRA. That would of course be lost for non-production upgrades with no JIRA. Oh well. Also though dependabot wouldn't put our JIRA in its commit messages. But for PRs where we file a JIRA we can require human edit of the dependabot PR title to reference the JIRA. That will result in the JIRA appearing in the log via the merge commit Github generates. That solves the git log use case adequately enough IMO.

Thoughts? [1] https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... [2] https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... Best regards, Brian _______________________________________________ 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...

Since I've been one that keeps talking about this, it seems I should reply here as well :) In general we could, and really probably should, start with a known set of dependencies to upgrade. Otherwise we'll probably see A LOT of dependency upgrade PR's. One thing to note too is that dependabot will create a branch in the repository. Anyone doing a fetch locally will get this new branch. Not really a huge deal, but something to keep in mind. Locally you might want to run git remote prune <your_remote> a little more often if you like to keep things clean :) On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > Occasionally we've thought about turning on dependabot for the main > WildFly repo, and a couple current discussions (see [1] and [2]) relate to > that, so it seems a good time to discuss further and perhaps take action. > > My main concern with dependabot is it doesn't integrate with JIRA. JIRA > is really important to how we're able to keep a handle on a project as > complex as WildFly. And I think it's important to track component upgrades > in JIRA so our users can keep an eye on what we're providing. Particularly > important in the world of ubiquitous CVE scanners. > > But James Perkins has pointed out that such JIRA tracking is kind of > overkill for non-production dependencies (e.g. test and build deps) and I > agree. > > So, how about we turn on dependabot and require a JIRA to be filed and > linked to the PR if the proposed upgrade is production code dep? For > non-production deps a JIRA would be optional. > > The other thing I care about a lot is being able to grep the git log for > commits related to a JIRA. That would of course be lost for non-production > upgrades with no JIRA. Oh well. Also though dependabot wouldn't put our > JIRA in its commit messages. But for PRs where we file a JIRA we can > require human edit of the dependabot PR title to reference the JIRA. That > will result in the JIRA appearing in the log via the merge commit Github > generates. That solves the git log use case adequately enough IMO. > TBH I only grep for JIRA's if I have the JIRA I'm trying to find the commit for. Short of that, I pretty much just use git blame on the file to find out which commit changed a line. But everyone has their own workflow and I don't want to push mine on anyone :)

> > Thoughts? > > [1] > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > [2] > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > > Best regards, > Brian > _______________________________________________ > 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... > -- James R. Perkins JBoss by Red Hat

On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > Since I've been one that keeps talking about this, it seems I should > reply here as well :) > > In general we could, and really probably should, start with a known set > of dependencies to upgrade. Otherwise we'll probably see A LOT of > dependency upgrade PR's. > Can we start by just doing this in dependabot.yml: ignore: - dependency-name: "*" update-types: ["version-update:semver-major", "version-update:semver-minor"]

So we limit things to just the micros. Dependabot will only produce 5 open PRs at a time, unless we specify a different number via dependabot.yml.* So we can process 5 at a time and even quickly close ones that will require more thought than we want to spend at that time. The dependency update report that's sent to this list every week will prevent any we ignore or close from falling into a crack. * Perhaps we should start with a smaller max number and increase it every day or so until we get to whatever our long-term target is. IOW, avoid an initial CI-hogging flood.

> One thing to note too is that dependabot will create a branch in the > repository. Anyone doing a fetch locally will get this new branch. Not > really a huge deal, but something to keep in mind. Locally you might want > to run git remote prune <your_remote> a little more often if you like to > keep things clean :) > Thanks for the tip! > > On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Occasionally we've thought about turning on dependabot for the main >> WildFly repo, and a couple current discussions (see [1] and [2]) relate to >> that, so it seems a good time to discuss further and perhaps take action. >> >> My main concern with dependabot is it doesn't integrate with JIRA. JIRA >> is really important to how we're able to keep a handle on a project as >> complex as WildFly. And I think it's important to track component upgrades >> in JIRA so our users can keep an eye on what we're providing. Particularly >> important in the world of ubiquitous CVE scanners. >> >> But James Perkins has pointed out that such JIRA tracking is kind of >> overkill for non-production dependencies (e.g. test and build deps) and I >> agree. >> >> So, how about we turn on dependabot and require a JIRA to be filed and >> linked to the PR if the proposed upgrade is production code dep? For >> non-production deps a JIRA would be optional. >> >> The other thing I care about a lot is being able to grep the git log for >> commits related to a JIRA. That would of course be lost for non-production >> upgrades with no JIRA. Oh well. Also though dependabot wouldn't put our >> JIRA in its commit messages. But for PRs where we file a JIRA we can >> require human edit of the dependabot PR title to reference the JIRA. That >> will result in the JIRA appearing in the log via the merge commit Github >> generates. That solves the git log use case adequately enough IMO. >> > > TBH I only grep for JIRA's if I have the JIRA I'm trying to find the > commit for. Short of that, I pretty much just use git blame on the file to > find out which commit changed a line. But everyone has their own workflow > and I don't want to push mine on anyone :) > > >> >> Thoughts? >> >> [1] >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >> [2] >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >> >> Best regards, >> Brian >> _______________________________________________ >> 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... >> > > > -- > James R. Perkins > JBoss by Red Hat > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

On Fri, Jul 28, 2023 at 1:03 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > On Fri, Jul 28, 2023 at 9:26 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> >>> Since I've been one that keeps talking about this, it seems I should >>> reply here as well :) >>> >>> In general we could, and really probably should, start with a known set >>> of dependencies to upgrade. Otherwise we'll probably see A LOT of >>> dependency upgrade PR's. >>> >> >> Can we start by just doing this in dependabot.yml: >> >> ignore: >> - dependency-name: "*" >> update-types: ["version-update:semver-major", >> "version-update:semver-minor"] >> > > We could, yes. We will likely have a lot of upgrades come in that way. > This might be okay, but my initial thought was to list specific > dependencies we know to be upgradeable without a JIRA. I'm definitely up > for being aggressive if we want though :) > I'll confess to being too lazy to try and figure out which deps to allow. :) > >> >> So we limit things to just the micros. >> >> Dependabot will only produce 5 open PRs at a time, unless we specify a >> different number via dependabot.yml.* So we can process 5 at a time and >> even quickly close ones that will require more thought than we want to >> spend at that time. The dependency update report that's sent to this list >> every week will prevent any we ignore or close from falling into a crack. >> >> >> * Perhaps we should start with a smaller max number and increase it >> every day or so until we get to whatever our long-term target is. IOW, >> avoid an initial CI-hogging flood. >> > > The CI concerns are definitely valid. I hadn't considered that. > I don't think it's *that* big a deal if our long term target is fairly small. Like if we turned it on on a Friday afternoon not near any tagging deadline probably no one would even notice the load. We need to be careful about rebase-strategy though. Having say 5 PRs continually rebasing and kicking off CI every time we merge would be bad. Probably we should turn it off and use the pull player /retest when we want a retest, same as we do with human-created PRs. https://docs.github.com/en/code-security/dependabot/dependabot-version-up... > >> >> >> >>> One thing to note too is that dependabot will create a branch in the >>> repository. Anyone doing a fetch locally will get this new branch. Not >>> really a huge deal, but something to keep in mind. Locally you might want >>> to run git remote prune <your_remote> a little more often if you like to >>> keep things clean :) >>> >> >> Thanks for the tip! >> >> >>> >>> On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Occasionally we've thought about turning on dependabot for the main >>>> WildFly repo, and a couple current discussions (see [1] and [2]) relate to >>>> that, so it seems a good time to discuss further and perhaps take action. >>>> >>>> My main concern with dependabot is it doesn't integrate with JIRA. >>>> JIRA is really important to how we're able to keep a handle on a project as >>>> complex as WildFly. And I think it's important to track component upgrades >>>> in JIRA so our users can keep an eye on what we're providing. Particularly >>>> important in the world of ubiquitous CVE scanners. >>>> >>>> But James Perkins has pointed out that such JIRA tracking is kind of >>>> overkill for non-production dependencies (e.g. test and build deps) and I >>>> agree. >>>> >>>> So, how about we turn on dependabot and require a JIRA to be filed and >>>> linked to the PR if the proposed upgrade is production code dep? For >>>> non-production deps a JIRA would be optional. >>>> >>>> The other thing I care about a lot is being able to grep the git log >>>> for commits related to a JIRA. That would of course be lost for >>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>> JIRA we can require human edit of the dependabot PR title to reference the >>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>> commit Github generates. That solves the git log use case adequately enough >>>> IMO. >>>> >>> >>> TBH I only grep for JIRA's if I have the JIRA I'm trying to find the >>> commit for. Short of that, I pretty much just use git blame on the file to >>> find out which commit changed a line. But everyone has their own workflow >>> and I don't want to push mine on anyone :) >>> >>> >>>> >>>> Thoughts? >>>> >>>> [1] >>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>> [2] >>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>> >>>> Best regards, >>>> Brian >>>> _______________________________________________ >>>> 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... >>>> >>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> > > > -- > James R. Perkins > JBoss by Red Hat > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

On Fri, Jul 28, 2023 at 8:06 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > > On Fri, Jul 28, 2023 at 1:03 PM James Perkins <jperkins(a)redhat.com&gt; > wrote: > >> >> >> On Fri, Jul 28, 2023 at 9:26 AM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; >>> wrote: >>> >>>> Since I've been one that keeps talking about this, it seems I should >>>> reply here as well :) >>>> >>>> In general we could, and really probably should, start with a known >>>> set of dependencies to upgrade. Otherwise we'll probably see A LOT of >>>> dependency upgrade PR's. >>>> >>> >>> Can we start by just doing this in dependabot.yml: >>> >>> ignore: >>> - dependency-name: "*" >>> update-types: ["version-update:semver-major", >>> "version-update:semver-minor"] >>> >> >> We could, yes. We will likely have a lot of upgrades come in that way. >> This might be okay, but my initial thought was to list specific >> dependencies we know to be upgradeable without a JIRA. I'm definitely up >> for being aggressive if we want though :) >> > > I'll confess to being too lazy to try and figure out which deps to allow. > :) > > >> >>> >>> So we limit things to just the micros. >>> >>> Dependabot will only produce 5 open PRs at a time, unless we specify a >>> different number via dependabot.yml.* So we can process 5 at a time and >>> even quickly close ones that will require more thought than we want to >>> spend at that time. The dependency update report that's sent to this list >>> every week will prevent any we ignore or close from falling into a crack. >>> >>> >>> * Perhaps we should start with a smaller max number and increase it >>> every day or so until we get to whatever our long-term target is. IOW, >>> avoid an initial CI-hogging flood. >>> >> >> The CI concerns are definitely valid. I hadn't considered that. >> > > I don't think it's *that* big a deal if our long term target is fairly > small. Like if we turned it on on a Friday afternoon not near any tagging > deadline probably no one would even notice the load. > > We need to be careful about rebase-strategy though. Having say 5 PRs > continually rebasing and kicking off CI every time we merge would be bad. > Probably we should turn it off and use the pull player /retest when we want > a retest, same as we do with human-created PRs. > +1 this must rebase strategy of GitHub to me feels like the strategy of how can we make it feel more like SVN - we don't need rebases on our PRs and if we are concerned about a combo we do one aggregate PR to test together.

> > > https://docs.github.com/en/code-security/dependabot/dependabot-version-up... > > >> >>> >>> >>> >>>> One thing to note too is that dependabot will create a branch in the >>>> repository. Anyone doing a fetch locally will get this new branch. Not >>>> really a huge deal, but something to keep in mind. Locally you might want >>>> to run git remote prune <your_remote> a little more often if you like to >>>> keep things clean :) >>>> >>> >>> Thanks for the tip! >>> >>> >>>> >>>> On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> Occasionally we've thought about turning on dependabot for the main >>>>> WildFly repo, and a couple current discussions (see [1] and [2]) relate to >>>>> that, so it seems a good time to discuss further and perhaps take action. >>>>> >>>>> My main concern with dependabot is it doesn't integrate with JIRA. >>>>> JIRA is really important to how we're able to keep a handle on a project as >>>>> complex as WildFly. And I think it's important to track component upgrades >>>>> in JIRA so our users can keep an eye on what we're providing. Particularly >>>>> important in the world of ubiquitous CVE scanners. >>>>> >>>>> But James Perkins has pointed out that such JIRA tracking is kind of >>>>> overkill for non-production dependencies (e.g. test and build deps) and I >>>>> agree. >>>>> >>>>> So, how about we turn on dependabot and require a JIRA to be filed >>>>> and linked to the PR if the proposed upgrade is production code dep? For >>>>> non-production deps a JIRA would be optional. >>>>> >>>>> The other thing I care about a lot is being able to grep the git log >>>>> for commits related to a JIRA. That would of course be lost for >>>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>>> JIRA we can require human edit of the dependabot PR title to reference the >>>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>>> commit Github generates. That solves the git log use case adequately enough >>>>> IMO. >>>>> >>>> >>>> TBH I only grep for JIRA's if I have the JIRA I'm trying to find the >>>> commit for. Short of that, I pretty much just use git blame on the file to >>>> find out which commit changed a line. But everyone has their own workflow >>>> and I don't want to push mine on anyone :) >>>> >>>> >>>>> >>>>> Thoughts? >>>>> >>>>> [1] >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>> [2] >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>> >>>>> Best regards, >>>>> Brian >>>>> _______________________________________________ >>>>> 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... >>>>> >>>> >>>> >>>> -- >>>> James R. Perkins >>>> JBoss by Red Hat >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> He/Him/His >>> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > He/Him/His > _______________________________________________ > 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... >

On Thu, Aug 3, 2023 at 3:27 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > On Thu, Aug 3, 2023 at 2:55 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> On Fri, Jul 28, 2023 at 8:06 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> >>> On Fri, Jul 28, 2023 at 1:03 PM James Perkins <jperkins(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Fri, Jul 28, 2023 at 9:26 AM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Since I've been one that keeps talking about this, it seems I should >>>>>> reply here as well :) >>>>>> >>>>>> In general we could, and really probably should, start with a known >>>>>> set of dependencies to upgrade. Otherwise we'll probably see A LOT of >>>>>> dependency upgrade PR's. >>>>>> >>>>> >>>>> Can we start by just doing this in dependabot.yml: >>>>> >>>>> ignore: >>>>> - dependency-name: "*" >>>>> update-types: ["version-update:semver-major", >>>>> "version-update:semver-minor"] >>>>> >>>> >>>> We could, yes. We will likely have a lot of upgrades come in that way. >>>> This might be okay, but my initial thought was to list specific >>>> dependencies we know to be upgradeable without a JIRA. I'm definitely up >>>> for being aggressive if we want though :) >>>> >>> >>> I'll confess to being too lazy to try and figure out which deps to >>> allow. :) >>> >>> >>>> >>>>> >>>>> So we limit things to just the micros. >>>>> >>>>> Dependabot will only produce 5 open PRs at a time, unless we specify >>>>> a different number via dependabot.yml.* So we can process 5 at a time and >>>>> even quickly close ones that will require more thought than we want to >>>>> spend at that time. The dependency update report that's sent to this list >>>>> every week will prevent any we ignore or close from falling into a crack. >>>>> >>>>> >>>>> * Perhaps we should start with a smaller max number and increase it >>>>> every day or so until we get to whatever our long-term target is. IOW, >>>>> avoid an initial CI-hogging flood. >>>>> >>>> >>>> The CI concerns are definitely valid. I hadn't considered that. >>>> >>> >>> I don't think it's *that* big a deal if our long term target is fairly >>> small. Like if we turned it on on a Friday afternoon not near any tagging >>> deadline probably no one would even notice the load. >>> >>> We need to be careful about rebase-strategy though. Having say 5 PRs >>> continually rebasing and kicking off CI every time we merge would be bad. >>> Probably we should turn it off and use the pull player /retest when we want >>> a retest, same as we do with human-created PRs. >>> >> >> +1 this must rebase strategy of GitHub to me feels like the strategy of >> how can we make it feel more like SVN - we don't need rebases on our PRs >> and if we are concerned about a combo we do one aggregate PR to test >> together. >> > > I rebase PR's all the time :) That said, you can still rebase dependabot > PR's with a comment of @dependabot rebase. You could use recreate instead > as well. The main reason for the rebase though is when a PR has a conflict. > Yeah for merge conflicts rebases are often the best, it is more the GitHub options of deliberately updating commit history I am commenting on.

> > >> >> >>> >>> >>> https://docs.github.com/en/code-security/dependabot/dependabot-version-up... >>> >>> >>>> >>>>> >>>>> >>>>> >>>>>> One thing to note too is that dependabot will create a branch in the >>>>>> repository. Anyone doing a fetch locally will get this new branch. Not >>>>>> really a huge deal, but something to keep in mind. Locally you might want >>>>>> to run git remote prune <your_remote> a little more often if you like to >>>>>> keep things clean :) >>>>>> >>>>> >>>>> Thanks for the tip! >>>>> >>>>> >>>>>> >>>>>> On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Occasionally we've thought about turning on dependabot for the main >>>>>>> WildFly repo, and a couple current discussions (see [1] and [2]) relate to >>>>>>> that, so it seems a good time to discuss further and perhaps take action. >>>>>>> >>>>>>> My main concern with dependabot is it doesn't integrate with JIRA. >>>>>>> JIRA is really important to how we're able to keep a handle on a project as >>>>>>> complex as WildFly. And I think it's important to track component upgrades >>>>>>> in JIRA so our users can keep an eye on what we're providing. Particularly >>>>>>> important in the world of ubiquitous CVE scanners. >>>>>>> >>>>>>> But James Perkins has pointed out that such JIRA tracking is kind >>>>>>> of overkill for non-production dependencies (e.g. test and build deps) and >>>>>>> I agree. >>>>>>> >>>>>>> So, how about we turn on dependabot and require a JIRA to be filed >>>>>>> and linked to the PR if the proposed upgrade is production code dep? For >>>>>>> non-production deps a JIRA would be optional. >>>>>>> >>>>>>> The other thing I care about a lot is being able to grep the git >>>>>>> log for commits related to a JIRA. That would of course be lost for >>>>>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>>>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>>>>> JIRA we can require human edit of the dependabot PR title to reference the >>>>>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>>>>> commit Github generates. That solves the git log use case adequately enough >>>>>>> IMO. >>>>>>> >>>>>> >>>>>> TBH I only grep for JIRA's if I have the JIRA I'm trying to find the >>>>>> commit for. Short of that, I pretty much just use git blame on the file to >>>>>> find out which commit changed a line. But everyone has their own workflow >>>>>> and I don't want to push mine on anyone :) >>>>>> >>>>>> >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> [1] >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>> [2] >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>> >>>>>>> Best regards, >>>>>>> Brian >>>>>>> _______________________________________________ >>>>>>> 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... >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> James R. Perkins >>>>>> JBoss by Red Hat >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Architect, Red Hat JBoss EAP >>>>> He/Him/His >>>>> >>>> >>>> >>>> -- >>>> James R. Perkins >>>> JBoss by Red Hat >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> He/Him/His >>> _______________________________________________ >>> 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... >>> >> > > -- > James R. Perkins > JBoss by Red Hat >

It looks like it went pretty well this week in WildFly, time for doing the same for WildFly Core by enabling patch release upgrades? On Thu, Aug 3, 2023 at 5:25 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Thu, Aug 3, 2023 at 9:37 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> >> On Thu, Aug 3, 2023 at 3:27 PM James Perkins <jperkins(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Thu, Aug 3, 2023 at 2:55 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> >>>> On Fri, Jul 28, 2023 at 8:06 PM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jul 28, 2023 at 1:03 PM James Perkins <jperkins(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 28, 2023 at 9:26 AM Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> On Thu, Jul 27, 2023 at 5:54 PM James Perkins <jperkins(a)redhat.com&gt; >>>>>>> wrote: >>>>>>> >>>>>>>> Since I've been one that keeps talking about this, it seems I >>>>>>>> should reply here as well :) >>>>>>>> >>>>>>>> In general we could, and really probably should, start with a >>>>>>>> known set of dependencies to upgrade. Otherwise we'll probably see A LOT of >>>>>>>> dependency upgrade PR's. >>>>>>>> >>>>>>> >>>>>>> Can we start by just doing this in dependabot.yml: >>>>>>> >>>>>>> ignore: >>>>>>> - dependency-name: "*" >>>>>>> update-types: ["version-update:semver-major", >>>>>>> "version-update:semver-minor"] >>>>>>> >>>>>> >>>>>> We could, yes. We will likely have a lot of upgrades come in that >>>>>> way. This might be okay, but my initial thought was to list specific >>>>>> dependencies we know to be upgradeable without a JIRA. I'm definitely up >>>>>> for being aggressive if we want though :) >>>>>> >>>>> >>>>> I'll confess to being too lazy to try and figure out which deps to >>>>> allow. :) >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> So we limit things to just the micros. >>>>>>> >>>>>>> Dependabot will only produce 5 open PRs at a time, unless we >>>>>>> specify a different number via dependabot.yml.* So we can process 5 at a >>>>>>> time and even quickly close ones that will require more thought than we >>>>>>> want to spend at that time. The dependency update report that's sent to >>>>>>> this list every week will prevent any we ignore or close from falling into >>>>>>> a crack. >>>>>>> >>>>>>> >>>>>>> * Perhaps we should start with a smaller max number and increase it >>>>>>> every day or so until we get to whatever our long-term target is. IOW, >>>>>>> avoid an initial CI-hogging flood. >>>>>>> >>>>>> >>>>>> The CI concerns are definitely valid. I hadn't considered that. >>>>>> >>>>> >>>>> I don't think it's *that* big a deal if our long term target is >>>>> fairly small. Like if we turned it on on a Friday afternoon not near any >>>>> tagging deadline probably no one would even notice the load. >>>>> >>>>> We need to be careful about rebase-strategy though. Having say 5 PRs >>>>> continually rebasing and kicking off CI every time we merge would be bad. >>>>> Probably we should turn it off and use the pull player /retest when we want >>>>> a retest, same as we do with human-created PRs. >>>>> >>>> >>>> +1 this must rebase strategy of GitHub to me feels like the strategy >>>> of how can we make it feel more like SVN - we don't need rebases on our PRs >>>> and if we are concerned about a combo we do one aggregate PR to test >>>> together. >>>> >>> >>> I rebase PR's all the time :) That said, you can still rebase >>> dependabot PR's with a comment of @dependabot rebase. You could use >>> recreate instead as well. The main reason for the rebase though is when a >>> PR has a conflict. >>> >> >> Yeah for merge conflicts rebases are often the best, it is more the >> GitHub options of deliberately updating commit history I am commenting on. >> > > I suspect the idea behind automatic rebases is an expectation that the > branch update will trigger a fresh CI run. Or maybe if your CI isn't doing > a merge before testing, then you get more accurate tests. But we do merges, > and our main branch is too active to be continually retesting PRs every > time it changes. > > And pull player /retest works just fine for dependabot PRs too. The pull > player bot doesn't discriminate against other bots. ;) > > >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>> https://docs.github.com/en/code-security/dependabot/dependabot-version-up... >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> One thing to note too is that dependabot will create a branch in >>>>>>>> the repository. Anyone doing a fetch locally will get this new branch. Not >>>>>>>> really a huge deal, but something to keep in mind. Locally you might want >>>>>>>> to run git remote prune <your_remote> a little more often if you like to >>>>>>>> keep things clean :) >>>>>>>> >>>>>>> >>>>>>> Thanks for the tip! >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 26, 2023 at 10:33 AM Brian Stansberry < >>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Occasionally we've thought about turning on dependabot for the >>>>>>>>> main WildFly repo, and a couple current discussions (see [1] and [2]) >>>>>>>>> relate to that, so it seems a good time to discuss further and perhaps take >>>>>>>>> action. >>>>>>>>> >>>>>>>>> My main concern with dependabot is it doesn't integrate with >>>>>>>>> JIRA. JIRA is really important to how we're able to keep a handle on a >>>>>>>>> project as complex as WildFly. And I think it's important to track >>>>>>>>> component upgrades in JIRA so our users can keep an eye on what we're >>>>>>>>> providing. Particularly important in the world of ubiquitous CVE scanners. >>>>>>>>> >>>>>>>>> But James Perkins has pointed out that such JIRA tracking is kind >>>>>>>>> of overkill for non-production dependencies (e.g. test and build deps) and >>>>>>>>> I agree. >>>>>>>>> >>>>>>>>> So, how about we turn on dependabot and require a JIRA to be >>>>>>>>> filed and linked to the PR if the proposed upgrade is production code dep? >>>>>>>>> For non-production deps a JIRA would be optional. >>>>>>>>> >>>>>>>>> The other thing I care about a lot is being able to grep the git >>>>>>>>> log for commits related to a JIRA. That would of course be lost for >>>>>>>>> non-production upgrades with no JIRA. Oh well. Also though dependabot >>>>>>>>> wouldn't put our JIRA in its commit messages. But for PRs where we file a >>>>>>>>> JIRA we can require human edit of the dependabot PR title to reference the >>>>>>>>> JIRA. That will result in the JIRA appearing in the log via the merge >>>>>>>>> commit Github generates. That solves the git log use case adequately enough >>>>>>>>> IMO. >>>>>>>>> >>>>>>>> >>>>>>>> TBH I only grep for JIRA's if I have the JIRA I'm trying to find >>>>>>>> the commit for. Short of that, I pretty much just use git blame on the file >>>>>>>> to find out which commit changed a line. But everyone has their own >>>>>>>> workflow and I don't want to push mine on anyone :) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>>>> [2] >>>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Brian >>>>>>>>> _______________________________________________ >>>>>>>>> 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... >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> James R. Perkins >>>>>>>> JBoss by Red Hat >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Principal Architect, Red Hat JBoss EAP >>>>>>> He/Him/His >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> James R. Perkins >>>>>> JBoss by Red Hat >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Principal Architect, Red Hat JBoss EAP >>>>> He/Him/His >>>>> _______________________________________________ >>>>> 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... >>>>> >>>> >>> >>> -- >>> James R. Perkins >>> JBoss by Red Hat >>> >> > _______________________________________________ > 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... >

Using prospero would make the usage of dependabot obsolete. You would only need PRs if there is actually a functional change in the API (usage) of a component.

Carlo On 26-07-2023 19:32, Brian Stansberry wrote: Occasionally we've thought about turning on dependabot for the main WildFly repo, and a couple current discussions (see [1] and [2]) relate to that, so it seems a good time to discuss further and perhaps take action. My main concern with dependabot is it doesn't integrate with JIRA. JIRA is really important to how we're able to keep a handle on a project as complex as WildFly. And I think it's important to track component upgrades in JIRA so our users can keep an eye on what we're providing. Particularly important in the world of ubiquitous CVE scanners. But James Perkins has pointed out that such JIRA tracking is kind of overkill for non-production dependencies (e.g. test and build deps) and I agree. So, how about we turn on dependabot and require a JIRA to be filed and linked to the PR if the proposed upgrade is production code dep? For non-production deps a JIRA would be optional. The other thing I care about a lot is being able to grep the git log for commits related to a JIRA. That would of course be lost for non-production upgrades with no JIRA. Oh well. Also though dependabot wouldn't put our JIRA in its commit messages. But for PRs where we file a JIRA we can require human edit of the dependabot PR title to reference the JIRA. That will result in the JIRA appearing in the log via the merge commit Github generates. That solves the git log use case adequately enough IMO. Thoughts? [1] https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... [2] https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... Best regards, Brian _______________________________________________ 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... _______________________________________________ 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...