symfony-tools / carsonbot Goto Github PK

The WebhookController becomes more and more complex so I think we should use the EventDispatcher to simplify it and create a new github.hook event:

class CommentSubmissionListener implements EventSubscriberInterface {
    public function onGithubHook(HookEvent $event) {
        if ('issue_comment' !== $event->getEvent()) {
            return;
        }
        // ...

        $event->addReturn('Comment managed');
    }

    public static function getSubscribedEvents() {
        return array('github.hook' => 'onGithubHook');
    }
}

What do you think ?

This error shows up in the log:

app.ERROR: Failed dispatching "pull_request" event for "carsonbot-playground/symfony" repository. {"exception":"[object] (Doctrine\DBAL\Exception\NotNullConstraintViolationException(code: 0): An exception occurred while executing 'INSERT INTO task (repository_full_name, number, action, created_at, updated_at, verify_after) VALUES (?, ?, ?, ?, ?, ?)' with params ["carsonbot-playground\/symfony", 22, 4, "2021-05-31 14:10:11", "2021-05-31 14:10:11", "2021-06-01 10:10:11"]:\n\nSQLSTATE[23502]: Not null violation: 7 ERROR: null value in column "id" violates not-null constraint\nDETAIL: Failing row contains (null, carsonbot-playground/symfony, 22, 4, 2021-05-31 14:10:11, 2021-05-31 14:10:11, 2021-06-01 10:10:11). at /app/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractPostgreSQLDriver.php:64)\n[previous exception] [object] (Doctrine\DBAL\Driver\PDO\Exception(code: 23502): SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column "id" violates

Here is the only place we create a Task:

This error was fixed by PR #181. It just downgraded doctrine packages.

  - Removing doctrine/deprecations (v0.5.3)
  - Downgrading doctrine/common (3.1.2 => 3.0.2)
  - Downgrading doctrine/dbal (2.13.1 => 2.10.4)
  - Downgrading doctrine/doctrine-bundle (2.3.2 => 2.2.1)
  - Downgrading doctrine/inflector (2.0.3 => 1.4.4)
  - Downgrading doctrine/migrations (3.1.2 => 3.1.1)
  - Downgrading doctrine/orm (2.8.4 => 2.7.4)

Let's update them one by one.

• Upgrade to doctrine/common 3.1.2
• Upgrade to doctrine/dbal 2.13.1
• Upgrade to doctrine/doctrine-bundle 2.3.2
• Upgrade to doctrine/inflector 2.0.3
• Upgrade to doctrine/migrations 3.1.2
• Upgrade to doctrine/orm 2.8.4

For each action happening on an issue, the issue listener will perform API calls to retrieve the labels of an issue.
However, this is a useless call: the payload being submitted by github to the webhook already contains all informations about the issue as retrieved by the issue API, and this include the list of labels applied on it: https://developer.github.com/v3/activity/events/types/#issuecommentevent

We could use this information instead of making another call

Status: needs work should be added instead

Authors of a PR/issue should be prevented to change the status of their PR/issue to anything else but "Needs Review". So they cannot do:

• "Needs Review" -> "Reviewed"

However, they can do:

• "Needs Work" -> "Needs Review"

Dear Carsonbot,

Are you okay, dude?

I wrote you some issues and PRs. But nothing seems to move you.
Did I make something wrong?

Or maybe are you in troubles my friend? We can talk about it. I'm pretty sure everyone here would be glad to help you.

Best regards and warm wishes,

Ogi. 🐱

I've noticed more and more PRs/issues misses their labels lately, despite the proper format used in titles. Sometimes it doesn't work for labelling from titles, but works for community reviews. See symfony/symfony#21424 for instance.
Is this only about some Github services outages, Carsonbot crashes or anything else?

For debugging - and potentially for displaying later - we should log all the actions that Carson takes and why.

The README says:

Finally, the status will be "Needs review" after the author pushes changes to the PR.

However, I haven't yet experienced this. Most recent example where I manually had to switch the status: symfony/symfony#39696

(I'm not sure if this is a bug, or an invalid README, it can make sense to not automatically switch the status after a push)

Should this repo be moved to https://github.com/carsonbot/carsonbot? Would make it easier to find for potential contributors.

Currently, github.com is hard-coded. While Carson Bot is intended to be used on Symfony, I can see this being very useful for other people, and businesses may have an enterprise github installation. My suggestion be to remove the hard-coded values and provide a configuration option for these enterprise installations to point to the correct API endpoints.

What do you think about creating a CarsonbotBundle to allow people to use it in a regular app ?

This status is used currently when an issue is waiting for the up-stream code to be merged.

I guess it's a feature? :)

It will help when debugging

Once I provided a small PR for Symfony. Even months afterwards, I get some email notifications like

Hey!

I think @{MyUserName} has recently worked with this code. Maybe they can help review this?

Cheers!

Carsonbot

Sorry, but from my point of view, tagging me in some PRs is not what I want and is spamming. I'm not a core contributor to Symfony. And this decreases the likelyhood that I provide a bug fix again because then I'll probably get more notifications when something changes in other code areas.

Please provide some process to unsubscribe from being tagged in some random PRs

When a PR is (1) submitted (2?) updated, it's modified files should be scanned and used to set the appropriate component/bridge/bundle labels for the PR.

I just discovered that the conditions introduced in #87 are not enough for the documentation: If you click the edit this page button for the current documentation, you'll target 5.1 and not the default branch (the default branch is rendered as the "master" version in the docs).

So, at least for the docs, carsonbot should not set the milestone if the target branch is equal to the default branch or the current Symfony version. This information can probably be fetched from https://symfony.com/releases.json (which, if the cache is triggered at the right moment, can be cached for 6 months)

Hello.

I think I could be nice to auto ask a review based on the modified files.

For example, if someone modify the workflow component, carson will add me as a reviewer.

Of course, it will be optin for those who want this system because I would be very nice for me (low activity on "my" component) and a notification storm for other (like fab / niko / stof).

WDYT?

The symfony repository has such status, but carsonbot does not support it.

The state "Needs Decision" should be supported. This state informs deciders that they should look and vote about a PR.

Only core team members should be allowed to set this status.

Once #8 is implemented, the bot should fix the title prefixes of PRs whenever their component/bundle/bridge labels are changed:

• [<component>] prefixes should be added for each component/bundle/bridge label
• superfluous [xxx] prefixes (e.g. [WIP]) should be removed

The idea is to retain the component labels of a PR in the Git log.

That was @nicolas-grekas' idea but it's not recorded here: what if crasonbot would display a nice "Welcome new contributor, etc..." message to the first contributors?

It would be a nice place to reiterate over the contribution rules, the importance of tests, how will the review will be done, what is the difference between the versions they can use as base, etc...

If something goes wrong, I'd like to get an email about it.

To me, the "Confirmed" and "Unconfirmed" labels represent the two possible statuses of a bug, not a standalone kind of issue.

That's why I propose to change them into "Status: Confirmed" and "Status: Unconfirmed", assignable only on "Bug" labelled issues.

More, I would like to see "Status: Unconfirmed" automatically assigned at the same time of the "Bug" one when creating an issue and don't see the "Status : Reviewed/Needs review" labels anymore for these very same issues (Bug).
For bugs we are talking about confirmation, not review, labels are already in place.
For proposals/feature requests, talking of review doesn't feel adapted but we could still use it (for all issues that aren't bug reports).

WDYT?

This project still uses Flex 1.13, which does not work anymore: https://github.com/symfony-tools/carsonbot/runs/6194121044?check_suite_focus=true#step:5:258

I don't mean any disrespect with this, I really like carsonbot and what it does, but looking at how far Github actions has come lately I can't help but think it could be nice to implement all the actions there.

Advantages:

• Get a log of everything that happened within the GitHub repository (would solve #14 and also probably #13)
• Removes the need of hosting carsonbot somewhere - less moving parts
• No need to have a server running 24/7 for sporadic actions, so better for the environment
• Leverage actions created by others, such as https://github.com/actions/first-interaction - which would solve #63

Something to think about though would be that GitHub actions doesn't really work well with PHP, because you'd either need to install PHP on their running Ubuntu (takes about a minute) or use a Docker container (which needs to build first, also takes about a minute). So for fast feedback it would be preferred to write actions in NodeJS, which Github Actions can run natively. Since most actions are quite small I don't think that should be a real problem though.

If you think this is something you might be interested in I'd love to take a stab at implementing it 🙂

symfony/symfony-docs#14918

Carson isn't sure what to do here:

1. I posted it as [RateLimiter][Security] ...
2. Carson updates to [RateLimiter] [Security] ... (note the space!)
3. After a push, Carson updates to [RateLimiter][Security] ... (gone is the space)

In #8 @webmozart proposed a way to label PRs after scanning the files modified by the PR. I propose now an alternative way to auto-label PRs which would be easier to implement and which would help us in most of the cases.

If a user submits the following:

[Form] Allow usage of immutable collection

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | unsure
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets |
| License       | MIT
| Doc PR        |

1. We should consider the first bracketed prefix ([Form] in this case) as the name of the component/bundle/bridge.
2. We should consider the Bug fix? and New feature? answers to add the Bug and/or Feature labels.

Would be nice if [DI] in the title was aliased to DependencyInjection in labels :)

The bot adds "Status: needs review" even if I add "Status: needs work" in the PR description

The commit message generated by GH ensures that github will close the PR automatically, but this only happens when the merge commit reaches the default branch of the repo (2.8 currently).
Given that it sometimes takes more than 1 week to get 2.3 changes merged into 2.8, there are 2 cases currently:

• either the merger has to come and close it manually
• or the PR stays open while it is already merged, opening the door for mistakes.

It would be great if the bot could look for pushed commits in development branches (i.e. master and 2.*, but not feature branches created in the main repo by a core team member by mistake) and close PRs when it finds such a commit (GH has predefined commit messages which are easy to catch to identify such cases).

An extra feature could be to post a comment explaining why the PR appears as closed rather than merged (similar to what the documentation team is doing manually currently).

This is more an idea than a feature request:

The bot could manage the milestones of the project automatically. Whenever a new tag is released (e.g. 2.7.2), a milestone for the next version is created (e.g. 2.7.3). Likewise, when a new minor version is released (e.g. 2.7.0), a new milestone for the next version should be created (e.g. 2.8.0).

This feature really becomes useful when we set PR milestones automatically based on their base branch. For example, a PR based on branch 2.7 would be assigned to the latest 2.7 milestone (here: 2.7.3).

When a version is released and the corresponding milestone still contains open tickets, these tickets should be moved to the next milestone (e.g. 2.7.2 -> 2.7.3).

As a result, we could work on next versions more efficiently by checking which PRs and issues are assigned to particular milestones before doing a release.

Not sure if the work in this is warranted, but I think it could be useful. :)

Follows #209.

When fixing the base branch in the PR template, it would be nice to see an update from Carson, update or delete its message for two reasons:

1. to confirm that you fixed the base branch
2. to reduce the noise, an automated-comment telling about a fixed issue is not really useful I think

WDYT?

Hi,

On a (long ago) forgot issue I have, I just saw in GH notification of @carsonbot

Thank you for this issue.
There has not been a lot of activity here for a while. Has this been resolved?

Is the bot aware of responses ? If we wrote no etc ? Because like that, this message feel like a bottle thrown into the sea.

If yes, could be usefull to write it in the mesasge :) (like dependabot)
If no, maybe write what are the call to action expected after this message so that the dev can take action on that :)

I obviously understand the main aim of this bot, but felt like this specific message is not well understandable, thus this issue

Thank you,

The avatar appears in the issue/PR page for the action of adding the label:

As this is an official Symfony bot, what do you think about putting the Symfony logo as its avatar ? /cc @fabpot

Today to be able to have Needs Work, someone has to request changes, but IMHO just adding comments on the PR should be it, because commenting without requesting changes is like requesting changes IMHO ;).

Here is an example: carsonbot-playground/symfony#24

Since I didn't make the PR from a fork, the "allow from edit" is not available and default to false in the webhook..

Here is some quick things to note:

1. Make sure we set environment variable: BOT_USERNAME=carsonbot
2. Verify that we've created a PostgreSQL database correctly (#102)
3. Run database migrations (#102)

you could use https://github.com/digitalkaoz/issues or even https://github.com/digitalkaoz/IssuesBundle for interacting with github issues :)

The only common issue in symfony-docs contributions is that contributors submit their PRs against an unmaintained branch. Most of the times this is OK because our internal merge tool can switch the branch easily, but sometimes there are lots of merge conflicts.

Ideally, Carson Bot should detect if an unmaintained branch is used and add a comment telling the user about this and linking to https://symfony.com/releases where they can see the currently maintained branches.

Thanks!

Approval => reviewed status
Request changes => needs work status
Comment => nothing special (or inspect the summary of the review just like comments)

What do you think about adding a "Missing tests" label automatically added by Carsonbot?

The status "Ready for Merge" should be set automatically once a PR has received two :+1: by different deciders and no :-1:. See the Pull Request Voting Policy for details.

This label informs mergers that they can merge a PR.

See symfony/symfony#40240

Somehow, Carson correctly detected the OptionsResolver label. However, it then updates to remove the [OptionsResolver] title prefix.

It seems that the review summaries introduced by Github in "A whole new Github universe: Code better with reviews" are ignored by carsonbot.

See symfony/symfony#20418 (review) for instance.

E.g. I switched the Console label for a Process one in symfony/symfony-docs#14769 and now the title says [Process] [Console] ... .

Contributors often open PRs against one branch, but fill in a different target branch into the PR template.

It would be great if Carson could detect that and post a nice comment.

Today Symfony added a template to issues similar to the PR template. See a random example here of the template in action: symfony/symfony#20901

So we can now autolabel issues as "Bug", "Feature", etc.