Something else we have talked about in the past is skipping CI for certain
jobs.
There are separate discussions about moving docs out of WildFly which would
also help but that is just a discussion at the moment, with a bot it could
be useful for a minimal set of requirements be met before we trigger CI but
skipping ci for doc only PRs could be good. I assume this could be
achieved by some form of label that pull player also checks?
On Fri, Jul 28, 2023 at 12:02 AM James Perkins <jperkins(a)redhat.com> wrote:
On Thu, Jul 27, 2023 at 11:28 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
>
>
> On Thu, Jul 27, 2023 at 11:10 AM Darran Lofthouse <
> darran.lofthouse(a)jboss.com> 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.
>
At one point many years ago this worked in the pull-player and was removed
for some reason. It would be pretty easy to add this back there though if
this is something we want fixed. Using the bot is fine too though.
>
> 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>
>> 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> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jul 26, 2023 at 11:46 AM Brian Stansberry <
>>>> brian.stansberry(a)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.
>>>>>
>>>>
>>>> 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> 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> 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...
>
--
James R. Perkins
JBoss by Red Hat