On Thu, Jul 27, 2023 at 10:18 AM Martin Stefanko <mstefank@redhat.com> 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#get-the-combined-status-for-a-specific-reference. But of course, we can remove the status altogether? Would that be better?

Probably not; a warn icon would just be a subtle improvement. We can merge PRs regardless of these statuses, so mergers can ignore the red X or not.

Regular contributors should learn enough about our procedures to understand whether they truly need to jump through hoops to clear a red X they disagree with.

The red X is probably better for infrequent contributors, as it helps emphasize our requirements. For odd cases where we'd waive the requirements reviewers can always explain that in comments.


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

Ah, special rules would be nice. Basically don't complain about commit messages. Other rules related to the PR title or description humans can correct, or, in the less common case of non-production upgrades, we can ignore.
 

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? 

Sounds good to me. IMHO full WildFly is better as a broader set of developers will be able to provide feedback.


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@redhat.com> wrote:


On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry <brian.stansberry@redhat.com> 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.



+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@redhat.com> 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@redhat.com> 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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/MM5K33E4DP36H4GGZPMWMW7HTZMFAFQM/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/6XTQOZQXZF3EZIAB7NBLY3PGP53U5LHE/


--
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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/ZOLFFJ6I6ZUICNT4SE4DQMPOBHNUNV7V/


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His