Hi, we created a custom wildfly-github-bot that is ready to be deployed to wildfly/wildfly repository when we get the green light - https://github.com/xstefank/wildfly-github-bot. It is a Java application that listens for GitHub events and interacts with GitHub's public API. For now, it contains two main features: 1/ PR format verification Verifies the PR is in the expected format (WFLY-XYZ Test). A simple video showing this in action https://www.youtube.com/watch?v=RgD7RhEegdc. 2/ Automatic /cc comment based on the changed files in the PR: For instance, in https://github.com/xstefank/wildfly/pull/65 or https://github.com/xstefank/wildfly/pull/64 you can see that I'm mentioned because the commit changed a file under microprofile/lra subdirectory. The configuration lives in the project that is utilizing the bot - https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. As you can see, mostly everything is configurable. The bot is currently deployed in the custom OSD (OpenShift Dedicated) cluster that we got provisioned just for this purpose. I would be the main maintainer plus a few guys from SET backing me. The deployed bot is configured for the https://github.com/xstefank/wildfly repository. Feel free to open as many PRs as you'd like to experiment with the bot. Check the configuration file to see what you can do - https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. Of course, this is just a start. We can add automatic labels, CI triggers, review requests (if wanted), or milestones, etc. We are only limited by what can be done on GitHub. Thanks, Martin Stefanko Principal Software Engineer Middleware Runtimes Sustaining Engineering Team 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...

Thanks, Martin. I very much like the way it edits its comment as the PR evolves instead of creating new ones. The latter would be yuck; this is quite elegant. If the verification fails are there other display options besides the red X? Like the yellow ! triangle thing. I think of our PR format rules as less strictly enforced than things like having no relevant CI failures. And there are cases where we won't get things 100% the way we want; e.g. if we turn on dependabot we'll never get JIRA refs in the commit messages.

+1 to not having a commit count limit. I often ask for and get a lot of commits in PRs that do significant refactoring as the work can be broken down into incremental, independently valid that are easily understandable. This practice makes the overall work much easier to review and can assist the author to produce better work too. On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: > Thank Martin, I find this automation would be very useful. From the > current configuration, I would remove the commits quantity, I think it > would be difficult to define a good threshold for this value. Some > repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it > to compare the PR description, although ideally, it should replace it > completely...I guess. > > On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> Hi, >> >> we created a custom wildfly-github-bot that is ready to be deployed to >> wildfly/wildfly repository when we get the green light - >> https://github.com/xstefank/wildfly-github-bot. >> >> It is a Java application that listens for GitHub events and interacts >> with GitHub's public API. >> >> For now, it contains two main features: >> >> 1/ PR format verification >> >> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >> video showing this in action https://www.youtube.com/watch?v=RgD7RhEegdc >> . >> >> 2/ Automatic /cc comment based on the changed files in the PR: >> >> For instance, in https://github.com/xstefank/wildfly/pull/65 or >> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >> mentioned because the commit changed a file under microprofile/lra >> subdirectory. >> >> The configuration lives in the project that is utilizing the bot - >> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >> As you can see, mostly everything is configurable. >> >> The bot is currently deployed in the custom OSD (OpenShift Dedicated) >> cluster that we got provisioned just for this purpose. I would be the main >> maintainer plus a few guys from SET backing me. >> >> The deployed bot is configured for the >> https://github.com/xstefank/wildfly repository. Feel free to open as >> many PRs as you'd like to experiment with the bot. Check the configuration >> file to see what you can do - >> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >> >> Of course, this is just a start. We can add automatic labels, CI >> triggers, review requests (if wanted), or milestones, etc. We are only >> limited by what can be done on GitHub. >> >> Thanks, >> Martin Stefanko >> >> Principal Software Engineer >> Middleware Runtimes Sustaining Engineering Team >> 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... >> > _______________________________________________ > 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

Hi all, Thanks for the feedback. Yeray, the quantity check is optional. But we will remove it. We can use the template but what exactly do you have in mind? Brian, statuses are only failure, pending, and success - https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... But of course, we can remove the status altogether? Would that be better? For dependabot, we can disable the bot or make special rules if needed. James, GH actions are great for testing and overall basically actions around the code in the PR. But they are not restarted automatically for description, title change, or if someone adds a new comment. Which is what we want to catch. This is why it needs to be a standalone service. But we have a stable server where we can run the bot for wildfly, wildfly-core (others maybe in future) without issues. You see where I'm going with this `@wildfly-bot retest failed` :). And we could do the reviewers for sure. But I started with the mentions I see better email notifications from GH. Personal preference and we can change it for sure. Overall, great feedback so thank you all. Do you think we could experimentally set this up with either wildfly or wildfly-core? So we can continuously see what works and what doesn't with our PRs work? Cheers, Martin Stefanko Principal Software Engineer Middleware Runtimes Sustaining Engineering Team Red Hat On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Thanks, Martin. I very much like the way it edits its comment as the PR >> evolves instead of creating new ones. The latter would be yuck; this is >> quite elegant. >> >> If the verification fails are there other display options besides the >> red X? Like the yellow ! triangle thing. I think of our PR format rules as >> less strictly enforced than things like having no relevant CI failures. And >> there are cases where we won't get things 100% the way we want; e.g. if we >> turn on dependabot we'll never get JIRA refs in the commit messages. >> > > Re the dependabot aspect, I started a semi-related thread at > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > > >> +1 to not having a commit count limit. I often ask for and get a lot of >> commits in PRs that do significant refactoring as the work can be broken >> down into incremental, independently valid that are easily understandable. >> This practice makes the overall work much easier to review and can assist >> the author to produce better work too. >> >> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; wrote: >> >>> Thank Martin, I find this automation would be very useful. From the >>> current configuration, I would remove the commits quantity, I think it >>> would be difficult to define a good threshold for this value. Some >>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>> to compare the PR description, although ideally, it should replace it >>> completely...I guess. >>> >>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> we created a custom wildfly-github-bot that is ready to be deployed to >>>> wildfly/wildfly repository when we get the green light - >>>> https://github.com/xstefank/wildfly-github-bot. >>>> >>>> It is a Java application that listens for GitHub events and interacts >>>> with GitHub's public API. >>>> >>>> For now, it contains two main features: >>>> >>>> 1/ PR format verification >>>> >>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >>>> video showing this in action >>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>> >>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>> >>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>> mentioned because the commit changed a file under microprofile/lra >>>> subdirectory. >>>> >>>> The configuration lives in the project that is utilizing the bot - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> As you can see, mostly everything is configurable. >>>> >>>> The bot is currently deployed in the custom OSD (OpenShift Dedicated) >>>> cluster that we got provisioned just for this purpose. I would be the main >>>> maintainer plus a few guys from SET backing me. >>>> >>>> The deployed bot is configured for the >>>> https://github.com/xstefank/wildfly repository. Feel free to open as >>>> many PRs as you'd like to experiment with the bot. Check the configuration >>>> file to see what you can do - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> >>>> Of course, this is just a start. We can add automatic labels, CI >>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>> limited by what can be done on GitHub. >>>> >>>> Thanks, >>>> Martin Stefanko >>>> >>>> Principal Software Engineer >>>> Middleware Runtimes Sustaining Engineering Team >>>> 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... >>>> >>> _______________________________________________ >>> 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 >> > > > -- > 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 11:10 AM Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > A couple of other ideas. > > It would be nice to automate the rebase-this or equivalent labels, I > assume we can detect if a PR would merge cleanly through the API. > > Also for fixme type labels it would be nice to automatically remove them > after someone pushes to a branch, even when they can remove them themselves > these get left behind and PRs overlooked during future reviews. > Yeah, I stopped applying rebase-this and fixme labels because they just became noise. But if they are on a PR it definitely affects whether I invest time in it as I search for easy wins to reduce the size of the PR queue.

A similar label idea is applying 29.x etc if the target branch isn't main. > > On Thu, Jul 27, 2023 at 4:19 PM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> Hi all, >> >> Thanks for the feedback. >> >> Yeray, the quantity check is optional. But we will remove it. We can use >> the template but what exactly do you have in mind? >> >> Brian, statuses are only failure, pending, and success - >> https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... >> But of course, we can remove the status altogether? Would that be better? >> >> For dependabot, we can disable the bot or make special rules if needed. >> >> James, GH actions are great for testing and overall basically actions >> around the code in the PR. But they are not restarted automatically for >> description, title change, or if someone adds a new comment. Which is what >> we want to catch. This is why it needs to be a standalone service. But we >> have a stable server where we can run the bot for wildfly, wildfly-core >> (others maybe in future) without issues. You see where I'm going with this >> `@wildfly-bot retest failed` :). >> >> And we could do the reviewers for sure. But I started with the mentions >> I see better email notifications from GH. Personal preference and we can >> change it for sure. >> >> >> Overall, great feedback so thank you all. Do you think we could >> experimentally set this up with either wildfly or wildfly-core? So we can >> continuously see what works and what doesn't with our PRs work? >> >> Cheers, >> Martin Stefanko >> >> Principal Software Engineer >> Middleware Runtimes Sustaining Engineering Team >> Red Hat >> >> >> On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Thanks, Martin. I very much like the way it edits its comment as the >>>> PR evolves instead of creating new ones. The latter would be yuck; this is >>>> quite elegant. >>>> >>>> If the verification fails are there other display options besides the >>>> red X? Like the yellow ! triangle thing. I think of our PR format rules as >>>> less strictly enforced than things like having no relevant CI failures. And >>>> there are cases where we won't get things 100% the way we want; e.g. if we >>>> turn on dependabot we'll never get JIRA refs in the commit messages. >>>> >>> >>> Re the dependabot aspect, I started a semi-related thread at >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>> >>> >>>> +1 to not having a commit count limit. I often ask for and get a lot >>>> of commits in PRs that do significant refactoring as the work can be broken >>>> down into incremental, independently valid that are easily understandable. >>>> This practice makes the overall work much easier to review and can assist >>>> the author to produce better work too. >>>> >>>> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >>>> yborgess(a)redhat.com&gt; wrote: >>>> >>>>> Thank Martin, I find this automation would be very useful. From the >>>>> current configuration, I would remove the commits quantity, I think it >>>>> would be difficult to define a good threshold for this value. Some >>>>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>>>> to compare the PR description, although ideally, it should replace it >>>>> completely...I guess. >>>>> >>>>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> we created a custom wildfly-github-bot that is ready to be deployed >>>>>> to wildfly/wildfly repository when we get the green light - >>>>>> https://github.com/xstefank/wildfly-github-bot. >>>>>> >>>>>> It is a Java application that listens for GitHub events and >>>>>> interacts with GitHub's public API. >>>>>> >>>>>> For now, it contains two main features: >>>>>> >>>>>> 1/ PR format verification >>>>>> >>>>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >>>>>> video showing this in action >>>>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>>>> >>>>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>>>> >>>>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>>>> mentioned because the commit changed a file under microprofile/lra >>>>>> subdirectory. >>>>>> >>>>>> The configuration lives in the project that is utilizing the bot - >>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>>>> As you can see, mostly everything is configurable. >>>>>> >>>>>> The bot is currently deployed in the custom OSD (OpenShift >>>>>> Dedicated) cluster that we got provisioned just for this purpose. I would >>>>>> be the main maintainer plus a few guys from SET backing me. >>>>>> >>>>>> The deployed bot is configured for the >>>>>> https://github.com/xstefank/wildfly repository. Feel free to open >>>>>> as many PRs as you'd like to experiment with the bot. Check the >>>>>> configuration file to see what you can do - >>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml >>>>>> . >>>>>> >>>>>> Of course, this is just a start. We can add automatic labels, CI >>>>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>>>> limited by what can be done on GitHub. >>>>>> >>>>>> Thanks, >>>>>> Martin Stefanko >>>>>> >>>>>> Principal Software Engineer >>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>> 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... >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> 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... >> > -- 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...

Hi all, Thanks for the feedback. Yeray, the quantity check is optional. But we will remove it. We can use the template but what exactly do you have in mind? Brian, statuses are only failure, pending, and success - https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... But of course, we can remove the status altogether? Would that be better?

For dependabot, we can disable the bot or make special rules if needed.

James, GH actions are great for testing and overall basically actions around the code in the PR. But they are not restarted automatically for description, title change, or if someone adds a new comment. Which is what we want to catch. This is why it needs to be a standalone service. But we have a stable server where we can run the bot for wildfly, wildfly-core (others maybe in future) without issues. You see where I'm going with this `@wildfly-bot retest failed` :). And we could do the reviewers for sure. But I started with the mentions I see better email notifications from GH. Personal preference and we can change it for sure. Overall, great feedback so thank you all. Do you think we could experimentally set this up with either wildfly or wildfly-core? So we can continuously see what works and what doesn't with our PRs work?

Cheers, Martin Stefanko Principal Software Engineer Middleware Runtimes Sustaining Engineering Team Red Hat On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Thanks, Martin. I very much like the way it edits its comment as the PR >> evolves instead of creating new ones. The latter would be yuck; this is >> quite elegant. >> >> If the verification fails are there other display options besides the >> red X? Like the yellow ! triangle thing. I think of our PR format rules as >> less strictly enforced than things like having no relevant CI failures. And >> there are cases where we won't get things 100% the way we want; e.g. if we >> turn on dependabot we'll never get JIRA refs in the commit messages. >> > > Re the dependabot aspect, I started a semi-related thread at > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > > >> +1 to not having a commit count limit. I often ask for and get a lot of >> commits in PRs that do significant refactoring as the work can be broken >> down into incremental, independently valid that are easily understandable. >> This practice makes the overall work much easier to review and can assist >> the author to produce better work too. >> >> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; wrote: >> >>> Thank Martin, I find this automation would be very useful. From the >>> current configuration, I would remove the commits quantity, I think it >>> would be difficult to define a good threshold for this value. Some >>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>> to compare the PR description, although ideally, it should replace it >>> completely...I guess. >>> >>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> we created a custom wildfly-github-bot that is ready to be deployed to >>>> wildfly/wildfly repository when we get the green light - >>>> https://github.com/xstefank/wildfly-github-bot. >>>> >>>> It is a Java application that listens for GitHub events and interacts >>>> with GitHub's public API. >>>> >>>> For now, it contains two main features: >>>> >>>> 1/ PR format verification >>>> >>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >>>> video showing this in action >>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>> >>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>> >>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>> mentioned because the commit changed a file under microprofile/lra >>>> subdirectory. >>>> >>>> The configuration lives in the project that is utilizing the bot - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> As you can see, mostly everything is configurable. >>>> >>>> The bot is currently deployed in the custom OSD (OpenShift Dedicated) >>>> cluster that we got provisioned just for this purpose. I would be the main >>>> maintainer plus a few guys from SET backing me. >>>> >>>> The deployed bot is configured for the >>>> https://github.com/xstefank/wildfly repository. Feel free to open as >>>> many PRs as you'd like to experiment with the bot. Check the configuration >>>> file to see what you can do - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> >>>> Of course, this is just a start. We can add automatic labels, CI >>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>> limited by what can be done on GitHub. >>>> >>>> Thanks, >>>> Martin Stefanko >>>> >>>> Principal Software Engineer >>>> Middleware Runtimes Sustaining Engineering Team >>>> 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... >>>> >>> _______________________________________________ >>> 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 >> > > > -- > 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... >

Hi all, Thanks for the feedback. Yeray, the quantity check is optional. But we will remove it. We can use the template but what exactly do you have in mind?

Brian, statuses are only failure, pending, and success - https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... But of course, we can remove the status altogether? Would that be better? For dependabot, we can disable the bot or make special rules if needed. James, GH actions are great for testing and overall basically actions around the code in the PR. But they are not restarted automatically for description, title change, or if someone adds a new comment. Which is what we want to catch. This is why it needs to be a standalone service. But we have a stable server where we can run the bot for wildfly, wildfly-core (others maybe in future) without issues. You see where I'm going with this `@wildfly-bot retest failed` :). And we could do the reviewers for sure. But I started with the mentions I see better email notifications from GH. Personal preference and we can change it for sure. Overall, great feedback so thank you all. Do you think we could experimentally set this up with either wildfly or wildfly-core? So we can continuously see what works and what doesn't with our PRs work? Cheers, Martin Stefanko Principal Software Engineer Middleware Runtimes Sustaining Engineering Team Red Hat On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > > > On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Thanks, Martin. I very much like the way it edits its comment as the PR >> evolves instead of creating new ones. The latter would be yuck; this is >> quite elegant. >> >> If the verification fails are there other display options besides the >> red X? Like the yellow ! triangle thing. I think of our PR format rules as >> less strictly enforced than things like having no relevant CI failures. And >> there are cases where we won't get things 100% the way we want; e.g. if we >> turn on dependabot we'll never get JIRA refs in the commit messages. >> > > Re the dependabot aspect, I started a semi-related thread at > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... > > >> +1 to not having a commit count limit. I often ask for and get a lot of >> commits in PRs that do significant refactoring as the work can be broken >> down into incremental, independently valid that are easily understandable. >> This practice makes the overall work much easier to review and can assist >> the author to produce better work too. >> >> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; wrote: >> >>> Thank Martin, I find this automation would be very useful. From the >>> current configuration, I would remove the commits quantity, I think it >>> would be difficult to define a good threshold for this value. Some >>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>> to compare the PR description, although ideally, it should replace it >>> completely...I guess. >>> >>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> we created a custom wildfly-github-bot that is ready to be deployed to >>>> wildfly/wildfly repository when we get the green light - >>>> https://github.com/xstefank/wildfly-github-bot. >>>> >>>> It is a Java application that listens for GitHub events and interacts >>>> with GitHub's public API. >>>> >>>> For now, it contains two main features: >>>> >>>> 1/ PR format verification >>>> >>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >>>> video showing this in action >>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>> >>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>> >>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>> mentioned because the commit changed a file under microprofile/lra >>>> subdirectory. >>>> >>>> The configuration lives in the project that is utilizing the bot - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> As you can see, mostly everything is configurable. >>>> >>>> The bot is currently deployed in the custom OSD (OpenShift Dedicated) >>>> cluster that we got provisioned just for this purpose. I would be the main >>>> maintainer plus a few guys from SET backing me. >>>> >>>> The deployed bot is configured for the >>>> https://github.com/xstefank/wildfly repository. Feel free to open as >>>> many PRs as you'd like to experiment with the bot. Check the configuration >>>> file to see what you can do - >>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>> >>>> Of course, this is just a start. We can add automatic labels, CI >>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>> limited by what can be done on GitHub. >>>> >>>> Thanks, >>>> Martin Stefanko >>>> >>>> Principal Software Engineer >>>> Middleware Runtimes Sustaining Engineering Team >>>> 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... >>>> >>> _______________________________________________ >>> 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 >> > > > -- > 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... >

Hi, we are getting a lot good ideas here so I started writing this down - https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa.... The doc is editable so please feel free to add ideas there or just directly create issue in the bot repo https://github.com/xstefank/wildfly-github-bot/issues. I'll work with Brian to get this running on wildfly repo. Cheers, Martin On Fri, Jul 28, 2023 at 10:51 AM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: > On Thu, Jul 27, 2023 at 4:18 PM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> Hi all, >> >> Thanks for the feedback. >> >> Yeray, the quantity check is optional. But we will remove it. We can use >> the template but what exactly do you have in mind? >> >> > I have nothing in my mind for upstream projects. It was just a suggestion > as something that maybe the Bot could take into account. > > I only mentioned it because there are specific repositories that already > use a template, and I thought it could be easier to use that template to > define the Bot rules. However, looking at what is inside those templates, > I've realized that what makes sense is to use them as a guide and replace > them completely with the Bot own configurations, so, please ignore the > template mention I did before. > > >> Brian, statuses are only failure, pending, and success - >> https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... >> But of course, we can remove the status altogether? Would that be better? >> >> For dependabot, we can disable the bot or make special rules if needed. >> >> James, GH actions are great for testing and overall basically actions >> around the code in the PR. But they are not restarted automatically for >> description, title change, or if someone adds a new comment. Which is what >> we want to catch. This is why it needs to be a standalone service. But we >> have a stable server where we can run the bot for wildfly, wildfly-core >> (others maybe in future) without issues. You see where I'm going with this >> `@wildfly-bot retest failed` :). >> >> And we could do the reviewers for sure. But I started with the mentions >> I see better email notifications from GH. Personal preference and we can >> change it for sure. >> >> >> Overall, great feedback so thank you all. Do you think we could >> experimentally set this up with either wildfly or wildfly-core? So we can >> continuously see what works and what doesn't with our PRs work? >> >> Cheers, >> Martin Stefanko >> >> Principal Software Engineer >> Middleware Runtimes Sustaining Engineering Team >> Red Hat >> >> >> On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> >>> >>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < >>> brian.stansberry(a)redhat.com&gt; wrote: >>> >>>> Thanks, Martin. I very much like the way it edits its comment as the >>>> PR evolves instead of creating new ones. The latter would be yuck; this is >>>> quite elegant. >>>> >>>> If the verification fails are there other display options besides the >>>> red X? Like the yellow ! triangle thing. I think of our PR format rules as >>>> less strictly enforced than things like having no relevant CI failures. And >>>> there are cases where we won't get things 100% the way we want; e.g. if we >>>> turn on dependabot we'll never get JIRA refs in the commit messages. >>>> >>> >>> Re the dependabot aspect, I started a semi-related thread at >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>> >>> >>>> +1 to not having a commit count limit. I often ask for and get a lot >>>> of commits in PRs that do significant refactoring as the work can be broken >>>> down into incremental, independently valid that are easily understandable. >>>> This practice makes the overall work much easier to review and can assist >>>> the author to produce better work too. >>>> >>>> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >>>> yborgess(a)redhat.com&gt; wrote: >>>> >>>>> Thank Martin, I find this automation would be very useful. From the >>>>> current configuration, I would remove the commits quantity, I think it >>>>> would be difficult to define a good threshold for this value. Some >>>>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>>>> to compare the PR description, although ideally, it should replace it >>>>> completely...I guess. >>>>> >>>>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> we created a custom wildfly-github-bot that is ready to be deployed >>>>>> to wildfly/wildfly repository when we get the green light - >>>>>> https://github.com/xstefank/wildfly-github-bot. >>>>>> >>>>>> It is a Java application that listens for GitHub events and >>>>>> interacts with GitHub's public API. >>>>>> >>>>>> For now, it contains two main features: >>>>>> >>>>>> 1/ PR format verification >>>>>> >>>>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A simple >>>>>> video showing this in action >>>>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>>>> >>>>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>>>> >>>>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>>>> mentioned because the commit changed a file under microprofile/lra >>>>>> subdirectory. >>>>>> >>>>>> The configuration lives in the project that is utilizing the bot - >>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>>>> As you can see, mostly everything is configurable. >>>>>> >>>>>> The bot is currently deployed in the custom OSD (OpenShift >>>>>> Dedicated) cluster that we got provisioned just for this purpose. I would >>>>>> be the main maintainer plus a few guys from SET backing me. >>>>>> >>>>>> The deployed bot is configured for the >>>>>> https://github.com/xstefank/wildfly repository. Feel free to open >>>>>> as many PRs as you'd like to experiment with the bot. Check the >>>>>> configuration file to see what you can do - >>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml >>>>>> . >>>>>> >>>>>> Of course, this is just a start. We can add automatic labels, CI >>>>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>>>> limited by what can be done on GitHub. >>>>>> >>>>>> Thanks, >>>>>> Martin Stefanko >>>>>> >>>>>> Principal Software Engineer >>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>> 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... >>>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> -- >>> 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... >

One further point, on the notifications these should really be to more than one engineer - we should be working to eliminate needing single points of contact where we can for our codebase. One other point to be cautious of with notifications, I would like those submitting PRs to largely be the driver to getting them merged, i.e. don't just dump and run. For those of us with merge rights on the repo merging is actually more of an admin task, check we have sufficient reviews, kick off some more CI if needed to check for interactions - merge. We have already set up the permissions and we have sent some emails but maybe time for some reminders, contributors should be asking others to review their PRs (not just Brian) and they have access to the GitHub UI to do this. If they have not done this within 24 / 48 hours maybe something we could do with the bot is point them to some instructions / guidance to do this if they are in the correct group? On Tue, Aug 8, 2023 at 9:17 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > Hi all, > > the configuration file PR is up - > https://github.com/wildfly/wildfly/pull/17072. Please take a quick look > if you would like to propose any changes. Of course this file is dynamic, > so we can change it at any point when the Bot will be deployed. > > Cheers, > Martin Stefanko > > Principal Software Engineer > Middleware Runtimes Sustaining Engineering Team > Red Hat > > > On Fri, Jul 28, 2023 at 1:32 PM Martin Stefanko <mstefank(a)redhat.com&gt; > wrote: > >> Hi, >> >> we are getting a lot good ideas here so I started writing this down - >> https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa.... >> The doc is editable so please feel free to add ideas there or just directly >> create issue in the bot repo >> https://github.com/xstefank/wildfly-github-bot/issues. I'll work with >> Brian to get this running on wildfly repo. >> >> Cheers, >> Martin >> >> >> On Fri, Jul 28, 2023 at 10:51 AM Yeray Borges Santana < >> yborgess(a)redhat.com&gt; wrote: >> >>> On Thu, Jul 27, 2023 at 4:18 PM Martin Stefanko <mstefank(a)redhat.com&gt; >>> wrote: >>> >>>> Hi all, >>>> >>>> Thanks for the feedback. >>>> >>>> Yeray, the quantity check is optional. But we will remove it. We can >>>> use the template but what exactly do you have in mind? >>>> >>>> >>> I have nothing in my mind for upstream projects. It was just a >>> suggestion as something that maybe the Bot could take into account. >>> >>> I only mentioned it because there are specific repositories that >>> already use a template, and I thought it could be easier to use that >>> template to define the Bot rules. However, looking at what is inside those >>> templates, I've realized that what makes sense is to use them as a guide >>> and replace them completely with the Bot own configurations, so, please >>> ignore the template mention I did before. >>> >>> >>>> Brian, statuses are only failure, pending, and success - >>>> https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... >>>> But of course, we can remove the status altogether? Would that be better? >>>> >>>> For dependabot, we can disable the bot or make special rules if needed. >>>> >>>> James, GH actions are great for testing and overall basically actions >>>> around the code in the PR. But they are not restarted automatically for >>>> description, title change, or if someone adds a new comment. Which is what >>>> we want to catch. This is why it needs to be a standalone service. But we >>>> have a stable server where we can run the bot for wildfly, wildfly-core >>>> (others maybe in future) without issues. You see where I'm going with this >>>> `@wildfly-bot retest failed` :). >>>> >>>> And we could do the reviewers for sure. But I started with the >>>> mentions I see better email notifications from GH. Personal preference and >>>> we can change it for sure. >>>> >>>> >>>> Overall, great feedback so thank you all. Do you think we could >>>> experimentally set this up with either wildfly or wildfly-core? So we can >>>> continuously see what works and what doesn't with our PRs work? >>>> >>>> Cheers, >>>> Martin Stefanko >>>> >>>> Principal Software Engineer >>>> Middleware Runtimes Sustaining Engineering Team >>>> Red Hat >>>> >>>> >>>> On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < >>>> brian.stansberry(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < >>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>> >>>>>> Thanks, Martin. I very much like the way it edits its comment as the >>>>>> PR evolves instead of creating new ones. The latter would be yuck; this is >>>>>> quite elegant. >>>>>> >>>>>> If the verification fails are there other display options besides >>>>>> the red X? Like the yellow ! triangle thing. I think of our PR format rules >>>>>> as less strictly enforced than things like having no relevant CI failures. >>>>>> And there are cases where we won't get things 100% the way we want; e.g. if >>>>>> we turn on dependabot we'll never get JIRA refs in the commit messages. >>>>>> >>>>> >>>>> Re the dependabot aspect, I started a semi-related thread at >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>> >>>>> >>>>>> +1 to not having a commit count limit. I often ask for and get a lot >>>>>> of commits in PRs that do significant refactoring as the work can be broken >>>>>> down into incremental, independently valid that are easily understandable. >>>>>> This practice makes the overall work much easier to review and can assist >>>>>> the author to produce better work too. >>>>>> >>>>>> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>> >>>>>>> Thank Martin, I find this automation would be very useful. From the >>>>>>> current configuration, I would remove the commits quantity, I think it >>>>>>> would be difficult to define a good threshold for this value. Some >>>>>>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>>>>>> to compare the PR description, although ideally, it should replace it >>>>>>> completely...I guess. >>>>>>> >>>>>>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko < >>>>>>> mstefank(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> we created a custom wildfly-github-bot that is ready to be >>>>>>>> deployed to wildfly/wildfly repository when we get the green light - >>>>>>>> https://github.com/xstefank/wildfly-github-bot. >>>>>>>> >>>>>>>> It is a Java application that listens for GitHub events and >>>>>>>> interacts with GitHub's public API. >>>>>>>> >>>>>>>> For now, it contains two main features: >>>>>>>> >>>>>>>> 1/ PR format verification >>>>>>>> >>>>>>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A >>>>>>>> simple video showing this in action >>>>>>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>>>>>> >>>>>>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>>>>>> >>>>>>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>>>>>> https://github.com/xstefank/wildfly/pull/64 you can see that I'm >>>>>>>> mentioned because the commit changed a file under microprofile/lra >>>>>>>> subdirectory. >>>>>>>> >>>>>>>> The configuration lives in the project that is utilizing the bot >>>>>>>> - >>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>>>>>> As you can see, mostly everything is configurable. >>>>>>>> >>>>>>>> The bot is currently deployed in the custom OSD (OpenShift >>>>>>>> Dedicated) cluster that we got provisioned just for this purpose. I would >>>>>>>> be the main maintainer plus a few guys from SET backing me. >>>>>>>> >>>>>>>> The deployed bot is configured for the >>>>>>>> https://github.com/xstefank/wildfly repository. Feel free to open >>>>>>>> as many PRs as you'd like to experiment with the bot. Check the >>>>>>>> configuration file to see what you can do - >>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml >>>>>>>> . >>>>>>>> >>>>>>>> Of course, this is just a start. We can add automatic labels, CI >>>>>>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>>>>>> limited by what can be done on GitHub. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin Stefanko >>>>>>>> >>>>>>>> Principal Software Engineer >>>>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>>>> 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... >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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... >>> >> _______________________________________________ > 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... >

Darran's input is valid but I don't think we should block on adding more names. I suggest that we instead go ahead with what you have (of course if people see other things that are wrong we should address those first) and then I'll send a PR adding my name to one section. I'll put the hold label on it. If other engineers want to add names they can send PRs to my branch. (Basically let's use my branch to aggregate the input, instead of having a bunch of PRs to wildfly/wildfly triggering pointless CI.) On the topic of getting PRs progressed, fyi re https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to.... Tom had the good suggestion yesterday that we note that on https://github.com/wildfly/wildfly/blob/main/docs/src/main/asciidoc/_hack.... We can update that page with content related to this bot (and more re the pull player) as well. Note also that James sent up a PR to enable dependabot -- https://github.com/wildfly/wildfly/pull/17057. I'd somewhat been sitting on that one as I figured it made sense to get wildfly-bot running first. On Tue, Aug 8, 2023 at 7:35 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > Darran, > > We did the config with Brian and I totally agree that more people should > be notified in every rule. But it's hard to define who should be notified. > Feel free to suggest changes if you know where we can add somebody. > > We can have the reminders implemented. Can you specify what exactly you > have in mind please? Maybe directly in > https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa... > . > > For instance, we plan to implement a test trigger, possibly replacing > pull-player to have something like /retest failed. We can also define a set > of checks that bot checks (similarly like format of the PR now) that will > add a label with the state of the PR. E.g., needs rebase, failing CI, > approved, ... anything we can imagine. > > Help me understand what your needs are as a merger please. > > Cheers, > Martin Stefanko > > Principal Software Engineer > Middleware Runtimes Sustaining Engineering Team > Red Hat > > > On Tue, Aug 8, 2023 at 10:32 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> One further point, on the notifications these should really be to more >> than one engineer - we should be working to eliminate needing single points >> of contact where we can for our codebase. >> >> One other point to be cautious of with notifications, I would like those >> submitting PRs to largely be the driver to getting them merged, i.e. don't >> just dump and run. For those of us with merge rights on the repo merging >> is actually more of an admin task, check we have sufficient reviews, kick >> off some more CI if needed to check for interactions - merge. >> >> We have already set up the permissions and we have sent some emails but >> maybe time for some reminders, contributors should be asking others to >> review their PRs (not just Brian) and they have access to the GitHub UI to >> do this. If they have not done this within 24 / 48 hours maybe something >> we could do with the bot is point them to some instructions / guidance to >> do this if they are in the correct group? >> >> On Tue, Aug 8, 2023 at 9:17 AM Martin Stefanko <mstefank(a)redhat.com&gt; >> wrote: >> >>> Hi all, >>> >>> the configuration file PR is up - >>> https://github.com/wildfly/wildfly/pull/17072. Please take a quick >>> look if you would like to propose any changes. Of course this file is >>> dynamic, so we can change it at any point when the Bot will be deployed. >>> >>> Cheers, >>> Martin Stefanko >>> >>> Principal Software Engineer >>> Middleware Runtimes Sustaining Engineering Team >>> Red Hat >>> >>> >>> On Fri, Jul 28, 2023 at 1:32 PM Martin Stefanko <mstefank(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> we are getting a lot good ideas here so I started writing this down - >>>> https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa.... >>>> The doc is editable so please feel free to add ideas there or just directly >>>> create issue in the bot repo >>>> https://github.com/xstefank/wildfly-github-bot/issues. I'll work with >>>> Brian to get this running on wildfly repo. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> On Fri, Jul 28, 2023 at 10:51 AM Yeray Borges Santana < >>>> yborgess(a)redhat.com&gt; wrote: >>>> >>>>> On Thu, Jul 27, 2023 at 4:18 PM Martin Stefanko <mstefank(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Thanks for the feedback. >>>>>> >>>>>> Yeray, the quantity check is optional. But we will remove it. We can >>>>>> use the template but what exactly do you have in mind? >>>>>> >>>>>> >>>>> I have nothing in my mind for upstream projects. It was just a >>>>> suggestion as something that maybe the Bot could take into account. >>>>> >>>>> I only mentioned it because there are specific repositories that >>>>> already use a template, and I thought it could be easier to use that >>>>> template to define the Bot rules. However, looking at what is inside those >>>>> templates, I've realized that what makes sense is to use them as a guide >>>>> and replace them completely with the Bot own configurations, so, please >>>>> ignore the template mention I did before. >>>>> >>>>> >>>>>> Brian, statuses are only failure, pending, and success - >>>>>> https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... >>>>>> But of course, we can remove the status altogether? Would that be better? >>>>>> >>>>>> For dependabot, we can disable the bot or make special rules if >>>>>> needed. >>>>>> >>>>>> James, GH actions are great for testing and overall basically >>>>>> actions around the code in the PR. But they are not restarted automatically >>>>>> for description, title change, or if someone adds a new comment. Which is >>>>>> what we want to catch. This is why it needs to be a standalone service. But >>>>>> we have a stable server where we can run the bot for wildfly, wildfly-core >>>>>> (others maybe in future) without issues. You see where I'm going with this >>>>>> `@wildfly-bot retest failed` :). >>>>>> >>>>>> And we could do the reviewers for sure. But I started with the >>>>>> mentions I see better email notifications from GH. Personal preference and >>>>>> we can change it for sure. >>>>>> >>>>>> >>>>>> Overall, great feedback so thank you all. Do you think we could >>>>>> experimentally set this up with either wildfly or wildfly-core? So we can >>>>>> continuously see what works and what doesn't with our PRs work? >>>>>> >>>>>> Cheers, >>>>>> Martin Stefanko >>>>>> >>>>>> Principal Software Engineer >>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>> Red Hat >>>>>> >>>>>> >>>>>> On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < >>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < >>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Thanks, Martin. I very much like the way it edits its comment as >>>>>>>> the PR evolves instead of creating new ones. The latter would be yuck; this >>>>>>>> is quite elegant. >>>>>>>> >>>>>>>> If the verification fails are there other display options besides >>>>>>>> the red X? Like the yellow ! triangle thing. I think of our PR format rules >>>>>>>> as less strictly enforced than things like having no relevant CI failures. >>>>>>>> And there are cases where we won't get things 100% the way we want; e.g. if >>>>>>>> we turn on dependabot we'll never get JIRA refs in the commit messages. >>>>>>>> >>>>>>> >>>>>>> Re the dependabot aspect, I started a semi-related thread at >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>> >>>>>>> >>>>>>>> +1 to not having a commit count limit. I often ask for and get a >>>>>>>> lot of commits in PRs that do significant refactoring as the work can be >>>>>>>> broken down into incremental, independently valid that are easily >>>>>>>> understandable. This practice makes the overall work much easier to review >>>>>>>> and can assist the author to produce better work too. >>>>>>>> >>>>>>>> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >>>>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> Thank Martin, I find this automation would be very useful. From >>>>>>>>> the current configuration, I would remove the commits quantity, I think it >>>>>>>>> would be difficult to define a good threshold for this value. Some >>>>>>>>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>>>>>>>> to compare the PR description, although ideally, it should replace it >>>>>>>>> completely...I guess. >>>>>>>>> >>>>>>>>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko < >>>>>>>>> mstefank(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> we created a custom wildfly-github-bot that is ready to be >>>>>>>>>> deployed to wildfly/wildfly repository when we get the green light - >>>>>>>>>> https://github.com/xstefank/wildfly-github-bot. >>>>>>>>>> >>>>>>>>>> It is a Java application that listens for GitHub events and >>>>>>>>>> interacts with GitHub's public API. >>>>>>>>>> >>>>>>>>>> For now, it contains two main features: >>>>>>>>>> >>>>>>>>>> 1/ PR format verification >>>>>>>>>> >>>>>>>>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A >>>>>>>>>> simple video showing this in action >>>>>>>>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>>>>>>>> >>>>>>>>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>>>>>>>> >>>>>>>>>> For instance, in https://github.com/xstefank/wildfly/pull/65 or >>>>>>>>>> https://github.com/xstefank/wildfly/pull/64 you can see that >>>>>>>>>> I'm mentioned because the commit changed a file under microprofile/lra >>>>>>>>>> subdirectory. >>>>>>>>>> >>>>>>>>>> The configuration lives in the project that is utilizing the >>>>>>>>>> bot - >>>>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>>>>>>>> As you can see, mostly everything is configurable. >>>>>>>>>> >>>>>>>>>> The bot is currently deployed in the custom OSD (OpenShift >>>>>>>>>> Dedicated) cluster that we got provisioned just for this purpose. I would >>>>>>>>>> be the main maintainer plus a few guys from SET backing me. >>>>>>>>>> >>>>>>>>>> The deployed bot is configured for the >>>>>>>>>> https://github.com/xstefank/wildfly repository. Feel free to >>>>>>>>>> open as many PRs as you'd like to experiment with the bot. Check the >>>>>>>>>> configuration file to see what you can do - >>>>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Of course, this is just a start. We can add automatic labels, CI >>>>>>>>>> triggers, review requests (if wanted), or milestones, etc. We are only >>>>>>>>>> limited by what can be done on GitHub. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martin Stefanko >>>>>>>>>> >>>>>>>>>> Principal Software Engineer >>>>>>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>>>>>> 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... >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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... >>>>> >>>> _______________________________________________ >>> 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... > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His

Thanks, Martin. I expanded item 2 in the dependabot section with a couple possibilities. I commented there re my shorter term preference. I don't think doing any of that is super urgent our should preclude merging the PR that turns on dependabot though. Humans can deal with the dependabot PRs just fine. On Wed, Aug 9, 2023 at 8:41 AM Martin Stefanko <mstefank(a)redhat.com&gt; wrote: > Please note that we didn't agree on dependabot PRs handling so there is > nothing Bot do/doesn't not do with regards to the Dependabot PRs. Can you > please comment on the document > https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa... > what is the preferred way of handling dependabot PRs? > > I agree that some information added to the contributing doc will be > useful so I will do it once the bot is deployed. > > Martin Stefanko > > Principal Software Engineer > Middleware Runtimes Sustaining Engineering Team > Red Hat > > > On Tue, Aug 8, 2023 at 6:52 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> Darran's input is valid but I don't think we should block on adding more >> names. >> >> I suggest that we instead go ahead with what you have (of course if >> people see other things that are wrong we should address those first) and >> then I'll send a PR adding my name to one section. I'll put the hold label >> on it. If other engineers want to add names they can send PRs to my branch. >> (Basically let's use my branch to aggregate the input, instead of having a >> bunch of PRs to wildfly/wildfly triggering pointless CI.) >> >> On the topic of getting PRs progressed, fyi re >> https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to.... >> Tom had the good suggestion yesterday that we note that on >> https://github.com/wildfly/wildfly/blob/main/docs/src/main/asciidoc/_hack.... >> We can update that page with content related to this bot (and more re the >> pull player) as well. >> >> Note also that James sent up a PR to enable dependabot -- >> https://github.com/wildfly/wildfly/pull/17057. I'd somewhat been >> sitting on that one as I figured it made sense to get wildfly-bot running >> first. >> >> >> >> On Tue, Aug 8, 2023 at 7:35 AM Martin Stefanko <mstefank(a)redhat.com&gt; >> wrote: >> >>> Darran, >>> >>> We did the config with Brian and I totally agree that more people >>> should be notified in every rule. But it's hard to define who should be >>> notified. Feel free to suggest changes if you know where we can add >>> somebody. >>> >> >> >>> We can have the reminders implemented. Can you specify what exactly you >>> have in mind please? Maybe directly in >>> https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa... >>> . >>> >>> For instance, we plan to implement a test trigger, possibly replacing >>> pull-player to have something like /retest failed. We can also define a set >>> of checks that bot checks (similarly like format of the PR now) that will >>> add a label with the state of the PR. E.g., needs rebase, failing CI, >>> approved, ... anything we can imagine. >>> >>> Help me understand what your needs are as a merger please. >>> >>> Cheers, >>> Martin Stefanko >>> >>> Principal Software Engineer >>> Middleware Runtimes Sustaining Engineering Team >>> Red Hat >>> >>> >>> On Tue, Aug 8, 2023 at 10:32 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> One further point, on the notifications these should really be to more >>>> than one engineer - we should be working to eliminate needing single points >>>> of contact where we can for our codebase. >>>> >>>> One other point to be cautious of with notifications, I would like >>>> those submitting PRs to largely be the driver to getting them merged, i.e. >>>> don't just dump and run. For those of us with merge rights on the repo >>>> merging is actually more of an admin task, check we have sufficient >>>> reviews, kick off some more CI if needed to check for interactions - merge. >>>> >>>> We have already set up the permissions and we have sent some emails >>>> but maybe time for some reminders, contributors should be asking others to >>>> review their PRs (not just Brian) and they have access to the GitHub UI to >>>> do this. If they have not done this within 24 / 48 hours maybe something >>>> we could do with the bot is point them to some instructions / guidance to >>>> do this if they are in the correct group? >>>> >>>> On Tue, Aug 8, 2023 at 9:17 AM Martin Stefanko <mstefank(a)redhat.com&gt; >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> the configuration file PR is up - >>>>> https://github.com/wildfly/wildfly/pull/17072. Please take a quick >>>>> look if you would like to propose any changes. Of course this file is >>>>> dynamic, so we can change it at any point when the Bot will be deployed. >>>>> >>>>> Cheers, >>>>> Martin Stefanko >>>>> >>>>> Principal Software Engineer >>>>> Middleware Runtimes Sustaining Engineering Team >>>>> Red Hat >>>>> >>>>> >>>>> On Fri, Jul 28, 2023 at 1:32 PM Martin Stefanko <mstefank(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> we are getting a lot good ideas here so I started writing this down >>>>>> - >>>>>> https://docs.google.com/document/d/1IbgDE9YMfYm2OvxC1W-1ikfQGmAJC0K60JfGa.... >>>>>> The doc is editable so please feel free to add ideas there or just directly >>>>>> create issue in the bot repo >>>>>> https://github.com/xstefank/wildfly-github-bot/issues. I'll work >>>>>> with Brian to get this running on wildfly repo. >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>>> >>>>>> >>>>>> On Fri, Jul 28, 2023 at 10:51 AM Yeray Borges Santana < >>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>> >>>>>>> On Thu, Jul 27, 2023 at 4:18 PM Martin Stefanko < >>>>>>> mstefank(a)redhat.com&gt; wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Thanks for the feedback. >>>>>>>> >>>>>>>> Yeray, the quantity check is optional. But we will remove it. We >>>>>>>> can use the template but what exactly do you have in mind? >>>>>>>> >>>>>>>> >>>>>>> I have nothing in my mind for upstream projects. It was just a >>>>>>> suggestion as something that maybe the Bot could take into account. >>>>>>> >>>>>>> I only mentioned it because there are specific repositories that >>>>>>> already use a template, and I thought it could be easier to use that >>>>>>> template to define the Bot rules. However, looking at what is inside those >>>>>>> templates, I've realized that what makes sense is to use them as a guide >>>>>>> and replace them completely with the Bot own configurations, so, please >>>>>>> ignore the template mention I did before. >>>>>>> >>>>>>> >>>>>>>> Brian, statuses are only failure, pending, and success - >>>>>>>> https://docs.github.com/en/rest/commits/statuses?apiVersion=2022-11-28#ge.... >>>>>>>> But of course, we can remove the status altogether? Would that be better? >>>>>>>> >>>>>>>> For dependabot, we can disable the bot or make special rules if >>>>>>>> needed. >>>>>>>> >>>>>>>> James, GH actions are great for testing and overall basically >>>>>>>> actions around the code in the PR. But they are not restarted automatically >>>>>>>> for description, title change, or if someone adds a new comment. Which is >>>>>>>> what we want to catch. This is why it needs to be a standalone service. But >>>>>>>> we have a stable server where we can run the bot for wildfly, wildfly-core >>>>>>>> (others maybe in future) without issues. You see where I'm going with this >>>>>>>> `@wildfly-bot retest failed` :). >>>>>>>> >>>>>>>> And we could do the reviewers for sure. But I started with the >>>>>>>> mentions I see better email notifications from GH. Personal preference and >>>>>>>> we can change it for sure. >>>>>>>> >>>>>>>> >>>>>>>> Overall, great feedback so thank you all. Do you think we could >>>>>>>> experimentally set this up with either wildfly or wildfly-core? So we can >>>>>>>> continuously see what works and what doesn't with our PRs work? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martin Stefanko >>>>>>>> >>>>>>>> Principal Software Engineer >>>>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>>>> Red Hat >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jul 26, 2023 at 7:35 PM Brian Stansberry < >>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry < >>>>>>>>> brian.stansberry(a)redhat.com&gt; wrote: >>>>>>>>> >>>>>>>>>> Thanks, Martin. I very much like the way it edits its comment as >>>>>>>>>> the PR evolves instead of creating new ones. The latter would be yuck; this >>>>>>>>>> is quite elegant. >>>>>>>>>> >>>>>>>>>> If the verification fails are there other display options >>>>>>>>>> besides the red X? Like the yellow ! triangle thing. I think of our PR >>>>>>>>>> format rules as less strictly enforced than things like having no relevant >>>>>>>>>> CI failures. And there are cases where we won't get things 100% the way we >>>>>>>>>> want; e.g. if we turn on dependabot we'll never get JIRA refs in the commit >>>>>>>>>> messages. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Re the dependabot aspect, I started a semi-related thread at >>>>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/thread/... >>>>>>>>> >>>>>>>>> >>>>>>>>>> +1 to not having a commit count limit. I often ask for and get a >>>>>>>>>> lot of commits in PRs that do significant refactoring as the work can be >>>>>>>>>> broken down into incremental, independently valid that are easily >>>>>>>>>> understandable. This practice makes the overall work much easier to review >>>>>>>>>> and can assist the author to produce better work too. >>>>>>>>>> >>>>>>>>>> On Wed, Jul 26, 2023 at 6:29 AM Yeray Borges Santana < >>>>>>>>>> yborgess(a)redhat.com&gt; wrote: >>>>>>>>>> >>>>>>>>>>> Thank Martin, I find this automation would be very useful. From >>>>>>>>>>> the current configuration, I would remove the commits quantity, I think it >>>>>>>>>>> would be difficult to define a good threshold for this value. Some >>>>>>>>>>> repositories already use a PULL_REQUEST_TEMPLATE.md, the bot could use it >>>>>>>>>>> to compare the PR description, although ideally, it should replace it >>>>>>>>>>> completely...I guess. >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 21, 2023 at 10:34 AM Martin Stefanko < >>>>>>>>>>> mstefank(a)redhat.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> we created a custom wildfly-github-bot that is ready to be >>>>>>>>>>>> deployed to wildfly/wildfly repository when we get the green light - >>>>>>>>>>>> https://github.com/xstefank/wildfly-github-bot. >>>>>>>>>>>> >>>>>>>>>>>> It is a Java application that listens for GitHub events and >>>>>>>>>>>> interacts with GitHub's public API. >>>>>>>>>>>> >>>>>>>>>>>> For now, it contains two main features: >>>>>>>>>>>> >>>>>>>>>>>> 1/ PR format verification >>>>>>>>>>>> >>>>>>>>>>>> Verifies the PR is in the expected format (WFLY-XYZ Test). A >>>>>>>>>>>> simple video showing this in action >>>>>>>>>>>> https://www.youtube.com/watch?v=RgD7RhEegdc. >>>>>>>>>>>> >>>>>>>>>>>> 2/ Automatic /cc comment based on the changed files in the PR: >>>>>>>>>>>> >>>>>>>>>>>> For instance, in https://github.com/xstefank/wildfly/pull/65 >>>>>>>>>>>> or https://github.com/xstefank/wildfly/pull/64 you can see >>>>>>>>>>>> that I'm mentioned because the commit changed a file under microprofile/lra >>>>>>>>>>>> subdirectory. >>>>>>>>>>>> >>>>>>>>>>>> The configuration lives in the project that is utilizing the >>>>>>>>>>>> bot - >>>>>>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml. >>>>>>>>>>>> As you can see, mostly everything is configurable. >>>>>>>>>>>> >>>>>>>>>>>> The bot is currently deployed in the custom OSD (OpenShift >>>>>>>>>>>> Dedicated) cluster that we got provisioned just for this purpose. I would >>>>>>>>>>>> be the main maintainer plus a few guys from SET backing me. >>>>>>>>>>>> >>>>>>>>>>>> The deployed bot is configured for the >>>>>>>>>>>> https://github.com/xstefank/wildfly repository. Feel free to >>>>>>>>>>>> open as many PRs as you'd like to experiment with the bot. Check the >>>>>>>>>>>> configuration file to see what you can do - >>>>>>>>>>>> https://github.com/xstefank/wildfly/blob/main/.github/wildfly-bot.yml >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> Of course, this is just a start. We can add automatic labels, >>>>>>>>>>>> CI triggers, review requests (if wanted), or milestones, etc. We are only >>>>>>>>>>>> limited by what can be done on GitHub. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Martin Stefanko >>>>>>>>>>>> >>>>>>>>>>>> Principal Software Engineer >>>>>>>>>>>> Middleware Runtimes Sustaining Engineering Team >>>>>>>>>>>> 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... >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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... >>>>>>> >>>>>> _______________________________________________ >>>>> 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... >>> >> >> >> -- >> Brian Stansberry >> Principal Architect, Red Hat JBoss EAP >> He/Him/His >> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His