META GitHub Bot #3238

moul · 2024-11-28T16:57:28Z

Do not hesitate to let me know if individual issues could be clearer, but I believe it's better to avoid the noise.

moul · 2024-11-28T16:58:38Z

So, here, I clicked on "the pull request description", then the bot switched back to unchecked. Should be persisted.

moul · 2024-11-28T16:59:02Z

Please change the logo; it is generally poor and not suitable for small sizes.

moul · 2024-11-28T17:00:30Z

The introduction should be aimed at those who are not familiar with the bot. It could say something like, "I'm a bot that assists the core team in maintaining this repository.

followed by the details."

Remove the h1.

moul · 2024-11-28T17:01:15Z

Group the two "details" into a single "debug" at the end.

aeddi · 2024-11-29T00:17:03Z

So, here, I clicked on "the pull request description", then the bot switched back to unchecked. Should be persisted.

Morgan already pinged me about this. The bot unchecks because it can't fetch the list of members from the core-contributors team, so it can't verify if you're allowed to check. It might be a token issue, I'll look into it today.

Also this one is weird: https://github.com/gnolang/gno/actions/runs/12072757244

Please change the logo; it is generally poor and not suitable for small sizes.

The introduction should be aimed at those who are not familiar with the bot. It could say something like, "I'm a bot that assists the core team in maintaining this repository."

Group the two "details" into a single "debug" at the end.

Ok 👍

aeddi · 2024-11-29T09:47:41Z

Another issue: https://github.com/gnolang/gno/actions/runs/12082335167/job/33693214789?pr=3096

Error: unable to update pull request: unable to create status on PR 3096: POST https://api.github.com/repos/gnolang/gno/statuses/2516635949b9e0b19e9b6a4c04115cf6fbf877c4: 403 Resource not accessible by personal access token []

moul · 2024-12-02T08:50:39Z

🔴 The pull request head branch must be up-to-date with its base

This is already blocked by GitHub settings.

You can keep the check if you believe the bot explains it better, but it shouldn't block the merge. It should be marked "orange" to indicate a warning.

aeddi · 2024-12-02T10:45:08Z

🔴 The pull request head branch must be up-to-date with its base

This is already blocked by GitHub settings.

You can keep the check if you believe the bot explains it better, but it shouldn't block the merge.

@moul I can disable it, just added it because it was one of the rule requested initially here, I think we should probably merge the fixes here first and then fine-tune the configuration.

It should be marked "orange" to indicate a warning.

I replaced all orange / pending / warning statuses by red / failed after answering this comment (see the response), basically for Github orange means "processing" and red means "failure" or "requirements not met". The CI is red when you don't have enough review yet for example (which is not an error but just an unmet requirement).

aeddi · 2024-12-02T11:44:37Z

Please change the logo; it is generally poor and not suitable for small sizes.

What about this one?

New avatar

thehowl · 2024-12-02T13:29:48Z

This is already blocked by GitHub settings.

Actually, not anymore; I don't recall exactly why, but this was disabled some short while ago.

aeddi · 2024-12-02T13:37:00Z

I always have this message in the checks of my PR:

Do you think it’s not blocking / that it doesn’t put the CI in "failure" state if everything else is green?

jefft0 · 2024-12-02T13:49:25Z

I agree that the "out-of-date with the base branch" message is unnecessary. In addition, it can lead the author of the PR to keep clicking the "Update branch" button, which we don't want. (See this message from Leon to a user who was doing this.)

This PR will allow debugging errors of [this type](https://github.com/gnolang/gno/actions/runs/12072757244) that unfortunately cannot be tested locally since they rely on the context of GitHub Actions. Since I also had to add flags to the matrix subcommand, I moved the two matrix and check subcommands into subfolders. This PR also modify the comment to stick to moul's request and fixes several Github Actions errors. Related to #3238 Changes: - d11ad5a moves matrix and check subcommands to their own packages in internal - 462ac01 5c1edda ffdce93 adds a debug to matrix subcommand (print event input / matrix output) + direct output of matrix to GitHub Actions using a matrix-key flag - 6af501d embed comment template file as a string at compile time instead of opening it at runtime - 59c3ad6 modifies bot comment to meet [this requirements](#3238 (comment)) - 241a755 filter out from the matrix generation and the PR processing all issues or closed PRs (process / list only opened PRs) <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests </details> --------- Co-authored-by: Morgan <[email protected]>

thehowl · 2024-12-02T18:00:13Z

I always have this message in the checks of my PR:

yeah, it's a warning, but not a requirement. maybe we can enable it back since Teritori is now submitting PRs which are modifiable by us, and we have a check to ensure that the branch is modifiable by maintainers.

moul · 2024-12-02T22:19:32Z

#3135 -> green, but red.

jefft0 · 2024-12-03T07:58:39Z

On PR #2597, the "stale bot" added the stale label and a comment. This triggered the meta guidelines bot to add a comment. Is this considered "activity" on the PR and does it reset the timer for the stale bot?

aeddi · 2024-12-03T12:53:51Z

#3135 -> green, but red.

Still the same error as here, basically, the bot is unable to create a commit status like this:

That's the last known issue for now. I created a test Github organisation and I'm currently trying to reproduce this issue to understand what settings needs to be modified on gnolang/gno.

aeddi · 2024-12-03T13:18:26Z

On PR #2597, the "stale bot" added the stale label and a comment. This triggered the meta guidelines bot to add a comment. Is this considered "activity" on the PR and does it reset the timer for the stale bot?

Mmmh yes I think it should unfortunately reset the stale timer, the stale bot will probably remove the label when it will run tonight at 1:30am.

I think there are two workarounds:

Run the GitHub Bot on the different open PRs to reset the timer now (rather than waiting for each of them to receive a stale label).
Add an if statement to the GitHub Actions bot workflow to ignore the 'labeled' event when the author happens to be the stale bot.

aeddi · 2024-12-03T15:33:25Z

Okay, I finally figured out what the issue was by brute-forcing random settings on an organization + a test repo with several users. The problem is that to create a commit status on a repo that belongs to an organization, the bot's PAT must not only have the commit statuses: read & write permission but also the associated account must either:

have an owner role in the gnolang organization (and not just a member)
have a write role in the gnolang/gno repo

And this is not documented anywhere as far as I know.
For anyone who comes across this, I also tried literally checking all the highest permissions on the PAT, but that didn't work either.

While these permissions are sufficient on the PAT as long as one of the two conditions mentioned above is met.

I also tried lower roles on the repo, but starting from triage, it no longer works. The minimum requirement is indeed to give the bot account a write role in the gno repo.

I will ask to someone with the admin role on gnolang/gno to give this role to the bot account, and everything should work normally.

jefft0 · 2024-12-04T09:54:55Z

On PR #2597, the "stale bot" added the stale label and a comment. This triggered the meta guidelines bot to add a comment. Is this considered "activity" on the PR and does it reset the timer for the stale bot?

Mmmh yes I think it should unfortunately reset the stale timer, the stale bot will probably remove the label when it will run tonight at 1:30am.

You're right, @aeddi . The stale bot removed the stale label on PR #2597 . This will cause lots of confusion. I prefer your option "Add an if statement to the GitHub Actions bot workflow to ignore the 'labeled' event when the author happens to be the stale bot." In general, I think the bots should ignore each other's actions.

Simple update of the bot README to mention the necessary permissions for the bot to operate, see this comment: #3238 (comment) <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests </details>

aeddi · 2024-12-04T11:05:48Z

@jefft0 Okay, so after digging a bit, I just saw that it wasn't the addition of the label by the stale bot that triggered the Gno bot. I think that the events emitted by the GitHub Actions account (used by the stale bot) are not forwarded to any other workflows, because even if the Gno bot is subscribed to the pull_request: labelled event, it's not fired by the stale bot applying a label.

However, what seems to have happened after analyzing the PR and this workflow run is that:

The stale bot, via the GitHub Actions account, applied the stale label.
This triggered Codecov, which is not an action or a workflow, but a GitHub app (which explains why it is triggered by events that are not forwarded to GitHub Actions workflows).
Codecov edited its own comment, which triggered the workflow of the Gno bot.

So I will ignore the events emitted by Codecov in the Gno bot's workflow, but I wonder if the fact that Codecov edits its own comment every time the stale bot adds the stale label generates activity on the PR that causes the stale bot to remove the label afterwards.

That could explained why the stale bot removed the label right after adding it on the PR you sent me on Signal, when the Gno bot was not running yet.

Edit: I just checked, and indeed, that seems to be the source of the problem. The Codecov comment was edited right after the label was added by the stale bot. I have no idea if we can disable this on Codecov, and I don't have access to the admin interface.

aeddi · 2024-12-04T15:03:29Z

FYI, the bot was just added as a contributor with a write role to the gno repo, so this last issue seems to be fixed : #3238 (comment)

jefft0 · 2024-12-05T08:24:47Z

FYI, the bot was just added as a contributor with a write role to the gno repo, so this last issue seems to be fixed : #3238 (comment)

Yes, good news. The stale bot just added the stale label on PR #2655, the GnoD2D bot added its comment, and the stale label is still there. :-)

aeddi · 2024-12-05T09:37:38Z

@jefft0 Unfortunately, I think the bot will notice the new comment and remove the label during its next run tonight at 1:30am.

I will open a PR to ignore event from codecov this morning.

Simple update of the bot README to mention the necessary permissions for the bot to operate, see this comment: gnolang#3238 (comment) <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests </details>

It's a bit of a "push and pray" since it would take too long to set up to reproduce this on my test repo/org, but I've triple-checked the documentation, the previous runs, etc., and it should be fine. Related to gnolang#3238 (comment) <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests </details>

See gnolang#3238 (comment) Signed-off-by: moul <[email protected]>

…#3303) This PR improves the bot on two points: - it now handle `pull_request_review` events to address [this concern](gnolang#3238 (comment)) gnolang@4f7b0b8 - a new condition allows to check if a PR was created from a fork to address [this concern](gnolang#3238 (comment)) gnolang@f491d95

This PR significantly modifies the github-bot's comment and adds a button to force the success of its CI check, even it the requirements provided in the config are not met. Related to #3238 (comment) **Edit**: I updated [the comment below](#3311 (comment)) by running the bot on my laptop if you want to see the result (so the skip button is not working yet).

thehowl · 2024-12-10T11:18:13Z

Edit: I think this can be the solution https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run

sounds good to try this out :)

aeddi · 2024-12-11T08:32:25Z

@gfanton warned me that the bot failed on his fork, which makes sense since the bot needs a token to work. I will simply add a condition to skip the bot workflow if the action variables/secrets are not set on the repo. This way, there will be no more failures on forks, and people who want to can still set up the bot on their fork.

github-project-automation bot added this to 🧙‍♂️gno.land core team Nov 28, 2024

github-project-automation bot moved this to Triage in 🧙‍♂️gno.land core team Nov 28, 2024

moul assigned aeddi Nov 28, 2024

aeddi mentioned this issue Nov 29, 2024

ci: add debug on github-bot matrix subcommand + fixes #3244

Merged

6 tasks

aeddi mentioned this issue Dec 3, 2024

docs: update token section in bot README #3261

Merged

6 tasks

r3v4s pushed a commit to gnoswap-labs/gno that referenced this issue Dec 10, 2024

chore: remove PR template (gnolang#3300)

4355770

See gnolang#3238 (comment) Signed-off-by: moul <[email protected]>

This was referenced Dec 10, 2024

fix: catch the out of gas exception in preprocess #2638

Merged

feat(examples): MDUI framework #2976

Open

aeddi mentioned this issue Dec 10, 2024

fix(github-bot): handle pull_request_review event from fork #3319

Open

Gno2D2 mentioned this issue Dec 11, 2024

feat(examples): add p/moul/cow #3325

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

META GitHub Bot #3238

META GitHub Bot #3238

moul commented Nov 28, 2024 •

edited

Loading

moul commented Nov 28, 2024

moul commented Nov 28, 2024

moul commented Nov 28, 2024 •

edited

Loading

moul commented Nov 28, 2024

aeddi commented Nov 29, 2024 •

edited

Loading

aeddi commented Nov 29, 2024

moul commented Dec 2, 2024

aeddi commented Dec 2, 2024 •

edited

Loading

aeddi commented Dec 2, 2024 •

edited

Loading

thehowl commented Dec 2, 2024

aeddi commented Dec 2, 2024

jefft0 commented Dec 2, 2024

thehowl commented Dec 2, 2024

moul commented Dec 2, 2024

jefft0 commented Dec 3, 2024

aeddi commented Dec 3, 2024

aeddi commented Dec 3, 2024

aeddi commented Dec 3, 2024

jefft0 commented Dec 4, 2024

aeddi commented Dec 4, 2024 •

edited

Loading

aeddi commented Dec 4, 2024

jefft0 commented Dec 5, 2024

aeddi commented Dec 5, 2024 •

edited

Loading

thehowl commented Dec 10, 2024

aeddi commented Dec 11, 2024

META GitHub Bot #3238

META GitHub Bot #3238

Comments

moul commented Nov 28, 2024 • edited Loading

moul commented Nov 28, 2024

moul commented Nov 28, 2024

moul commented Nov 28, 2024 • edited Loading

moul commented Nov 28, 2024

aeddi commented Nov 29, 2024 • edited Loading

aeddi commented Nov 29, 2024

moul commented Dec 2, 2024

aeddi commented Dec 2, 2024 • edited Loading

aeddi commented Dec 2, 2024 • edited Loading

thehowl commented Dec 2, 2024

aeddi commented Dec 2, 2024

jefft0 commented Dec 2, 2024

thehowl commented Dec 2, 2024

moul commented Dec 2, 2024

jefft0 commented Dec 3, 2024

aeddi commented Dec 3, 2024

aeddi commented Dec 3, 2024

aeddi commented Dec 3, 2024

jefft0 commented Dec 4, 2024

aeddi commented Dec 4, 2024 • edited Loading

aeddi commented Dec 4, 2024

jefft0 commented Dec 5, 2024

aeddi commented Dec 5, 2024 • edited Loading

thehowl commented Dec 10, 2024

aeddi commented Dec 11, 2024

moul commented Nov 28, 2024 •

edited

Loading

moul commented Nov 28, 2024 •

edited

Loading

aeddi commented Nov 29, 2024 •

edited

Loading

aeddi commented Dec 2, 2024 •

edited

Loading

aeddi commented Dec 2, 2024 •

edited

Loading

aeddi commented Dec 4, 2024 •

edited

Loading

aeddi commented Dec 5, 2024 •

edited

Loading