[wildfly-dev] Re: WildFly GitHub Bot

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 >