giteabot / gitea-backporter Goto Github PK

This is recommended in newer versions of deno

See go-gitea/gitea#29191. The bot did not remove the label after re-request which lifted the block. Maybe GitHub has changed something about this API because I recall this did work before.

Correctly, it should have removed lgtm/blocked and added lgtm/need-2.

Currently this is not possible using the GitHub REST API because re-requests or self-request after approval are not visible in the GitHub review REST API. I think the GraphQL API exposes these and we would have to use that API to correctly parse re-request.

Currently we just send a message, but maybe it's better to add a mention of original author.

<made a mistake, so the old comment was deleted, see the comment below>

Maybe it's upstream related.

go-gitea/gitea#26271 (comment)

The bot could accept a mention with a command like

@GiteaBot run `make fmt`

If this exact syntax is matched, check out the branch, run the command, and commit the results with a message run `make fmt` requested by @silverwind. Usage should be restricted to maintainer roles and above.

@techknowlogick or @jolheiser

Sometimes users (very kindly) add translations for other languages in their PR. We should add a gentle reminder to direct them to crowdin to let them know to contribute their changes there instead.

Maybe something like: "Hi, I noticed you've updated the locales for non-English languages. These will be overwritten during the sync from our translation tool Crowdin. If you'd like to contribute your translations, please visit https://crowdin.com/project/gitea."

If the webhook URL leaks, anyone will be able to trigger the bot and rate limit/ban the bot.

References:

• https://docs.github.com/en/webhooks-and-events/webhooks/securing-your-webhooks
• https://github.com/wtfiscrq/github_webhooks (https://deno.land/x/github_webhooks)

From go-gitea/gitea#25667 (comment), I think it would be useful if the bot could auto-set some labels based on modified path. There are two kind of matching mechanisms needed:

1. If any path is modified. For example, every change in Makefile should get a build label.
2. If only a path is modified. For example a change only in docs should get a kind/docs label and maybe a skip-changelog, but a change that includes changes in docs and templates should not.

The config should be in the repo itself in .github/giteabot.yaml to be flexible to change:

autolabels:
  only:
    - globs: [docs/**]
      labels: [kind/docs, skip-changelog]
  any:
    - globs: [Makefile]
      labels: [build]

Label additions are not atomic operations it seems:

Example PR: go-gitea/gitea#29856

go-gitea/gitea#24277 (comment)

go-gitea/gitea#25850 (comment)

The lgtm bot is essentially unmaintained and has a number of bugs:

• It forgets approval status after the branch is updated via merge and needs to be triggered with a comment to update status, which is very annoying.
• It incorrectly parses "LGTM after ..." from comments

I think we could replace it with lightweight functionality in this bot. The bot tasks are:

• Handle lgtm/need-* labels, a subtraction of required approver count against actual approvers.
• Add a commit status or check that suceeds if approval count is >= 2. See here for the diferences between the APIs.

Parsing comments is out of scope for this bot. It is simply not needed any more now that GH has the approvers data (the lgtm bot came from a time before this where a PR could only have a single approver).

For counting approvers, it should count maintainer role and above and this is where we differ from GitHub's view of approvers, where we allow even people without push access to approve and those are visible by the green checkmark. Maybe the upcoming repo rules will allow us to give maintainers a green checkmark.

I think this is caused by that v1.19 does not support any more, so bot can not find the correct milestone.
Maybe we can add a check of this in L14:

Might want to reconsider this given recent problem go-gitea/gitea#22854. I think as long as mergers have the option to merge PRs (likely via CLI) with stale negative reviews, it'll work out.

ref go-gitea/gitea#27367 (comment)

Empty original PR body triggers "null" in the backport message, should remove:

go-gitea/gitea#23852

I think the bot needs to track "done" status per target branch, in go-gitea/gitea#30193, it opened a second port backport to 1.21 after we closed the first one. Maybe backport/v1.21/done labels, or search existing PRs to do it label-less.

I know it's not the original purpose of the bot, but it would be useful if the bot would remove the label after any sucessful PR merge, even if the bot is not the author.

go-gitea/gitea#27503 is a clean cherry-pick against both 1.21 and 1.20, but the bot failed for unknown reasons. Here's how I do it, maybe the bot tries it differently?

git checkout release/v1.21
git reset --hard origin/release/v1.21
git checkout -b backport-27503-21
git cherry-pick 08efeb5
git push silverwind backport-27503-21

To avoid noise from the closed/merged issues/pull requests to ask users to create new issues, I think it's necessary to lock all old issues/pull requests.

Noticed this bug:

The committer of the translation updates is always set to the author of the previous commit. Correctly, GiteaBot should be both the author and committer.

go-gitea/gitea#22175

These were pretty much back-to-back:

ref: go-gitea/gitea#20745

As per our CoC:
If you start a last call, and no one reviews the PR within a week, you can consider this polite refusal and your PR will be closed.
This definition is automateable, especially now that we have the corresponding label.

The label could be named close_if_no_feedback or we can reuse need_feedback.

When an issue has a label need_feedback but there is no any comment one month after the label added. then close it automatically.

Suggested in go-gitea/gitea#24470 (comment)

Instead of the current message

The bot could point to the contrib/backport tool (untested):

`I was unable to create a backport for ${giteaVersion.majorMinorVersion}. @${originalPr.user.login}, please send one manually. :tea:

\`\`\`
go run ./contrib/backport ${originalPr.number}
...  // fix git conflicts if any
go run ./contrib/backport --continue
\`\`\`
`

ref go-gitea/gitea#26729

https://github.com/GiteaBot/gitea-backporter/actions/runs/4584934309/jobs/8096741750

When a PR is sent to the main branch, it should be assigned the max value of the milestones.
If a PR is sent to release/v1.19, it should be assigned the max value of 1.19.x milestones.

As we merge PRs, this code could also update 2-3 of the next-in-line PRs to be merged that have reviewed/wait-merge.

It may also be beneficial to do this per-branch, so we update things targeting main as well as release/v1.19 etc.

/cc @delvh

go-gitea/gitea#25721 (comment)

The webhook can call mod.ts's run directly