Provide a bot to close GitHub PRs of read-only mirrors

None of those options ;-) Web hooks are the wrong tool too I think.

This should be done with a Github Actions workflow with a on: [pull_request] trigger. This way it wouldn't require any infustructure and would only operate directly on the Github repo.

I've thought about this too. However, this would require a GitHub Actions file in the repositories, are we fine with that?

https://github.com/peter-evans/close-pull

And how would this work for the SVN Mirror repos?

As long as there is an Arch official mirror on Github I think having a .github folder with anything specific to it being there is probably okay. Another thing that could probably go in there is a PR template that warned people off before they even get their PR open. I'm sure opinions vary, but Actions are by far the lowest technical overhead way to set this up.

I'm not sure that action you linked to is the best option. Maybe this one?

I couldn't get the action you linked to work. peter-evans/close-pull worked right away and development seems to be more active.

name: Close all Pull Requests and comment on them
on: [pull_request]
jobs:
  close-prs:
    runs-on: ubuntu-latest
    steps:
      - name: Close Pull
        uses: peter-evans/close-pull@v1
        with:
          comment: Auto-closing pull request
          delete-branch: true

Multiline-Comments work like this:

          comment: > 
            # Markdown!
            
            Multiline!
            No!
            Sure!
            Oooh!

I haven't figured out how to use template files yet.

If it works then sure. I thought from skimming the descriptions (no testing) that it wasn't even suitable for the purpose. Apparently I was wrong.

I think i would be more ideal to create our own action, so we don't need to sync the template between repos. Then we can just add this workflow to all the mirrored repos:

name: Close all Pull Requests and comment on them
on: [pull_request]
jobs:
  close-prs:
    runs-on: ubuntu-latest
    steps:
      - name: Close Pull
        uses: archlinux/close-pull-repo

Creating our own action seems to be easy enough: https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action

Something like this:

await octokit.issues.createComment({
  owner: owner,
  repo: repo,
  issue_number: pullRequestNumber,
  body: inputs.comment
});
octokit.pulls.update({
  owner: owner,
  repo: repo,
  pull_number: pullRequestNumber,
  state: 'closed'
});

Another option is using a Github organisation webhook, which could call python/rust webserver which closes the pull request.

https://developer.github.com/v3/orgs/hooks/#create-an-organization-webhook https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads#pull_request

assigned to @lambdaclan and @ffy00

Hello everyone, I will also be helping out towards resolving this issue.

After going through the comments and the various links, I can see that we have plenty of options. Is everything on the table?

Saying that, after talking with Sven-Hendrik about this matter over at IRC it was emphasized that:

we don't want one workflow per repo as that's super annoying

we want one repo where it has the workflow and that operates on ALL of our repos

maintainability and less duplication need to be emphasized

Looking at some GitHub webhook info:

Each webhook can be installed on an organization or a specific repository. Once installed, they will be triggered each time one or more subscribed events occurs on that organization or repository like deployments, commits, and repository changes, etc

Using the information above, seems like the proposal from Jelle of using an organizational webhook to be the way to go.

I personally feel that Kristian's proposal seems to be the most versatile and "clean" since it is built in and will possibly require less effort than a webhooks based solution. If we create our own action we will have full control of what we can do and will avoid the need for web-hooks (which will also require a WSGI application) or polling. All we will need is a user token (owner or collaborator on all mirrored repos). After a short search it seems possible that we can automate the GitHub action sync across all the repos of the organization, something similar to this https://medium.com/@adrianjost/how-to-sync-github-actions-across-repositories-f0b09dc9a9d8

I mean adding the workflow to all the mirrored repos is also acceptable but it will be a manual process and depending on how often we create new repos could be problematic and it conflicts with the requirements mentioned above.

Now, which method is more maintainable I guess is open to discussion. Happy to discuss further but in the meantime I will start looking into both creating a custom GitHub action for our purposes as well as webhooks.

If we do go with webhooks in the end, is Python the preferred way or?

@svenstaro I will be using my account for the tests I guess that should be enough for now but not sure if I will also need access to the organization repos down the line.

All we will need is a user token (owner or collaborator on all mirrored repos)

We can just use the GITHUB_TOKEN, we don't need to create a PAT token.

I mean adding the workflow to all the mirrored repos is also acceptable but it will be a manual process and depending on how often we create new repos could be problematic and it conflicts with the requirements mentioned above.

Another option is running the workflow on a schedule, that would require a PAT token though. Then we don't need to add a workflow to every mirrored repository.

I have a working solution using a simple Python Flask webserver application acting as a listener to GitHub webhooks. It works pretty well and seems like a good option for what we are tying to do. This process does require a PAT and for our purposes an organizational PAT with full access to all the repos. It is also using a secret to verify the post request is coming from GitHub.

We will just need to be aware of rate limits abuse and how to deal with it.

@svenstaro I will need some feedback regarding the following points:

What type of events to manage. Currently I am only monitoring pull requests.
For each event type which action to monitor, for example for pull requests I am checking for "opened" and "reopened".
What to do once a PR is opened/reopend currently I add a comment and close it.
Is it OK to use a PAT with the repo permission?
Is a Python webserver acceptable?

Plus anything else you might want to add.

simplescreenrecorder-2020-08-18_16.35.08

Looks cool, some things I would like to bring up (note they are not that important right now):

Create a separate project this app when it's finalised, then we can easily package it and include it in our repos. We should be able to configure which repos to auto-close, as currently some are still on Github. Maybe a configuration option like repos: 'all' to close it for all repository's.

What to do once a PR is opened/reopend currently I add a comment and close it.

I wonder if we want to make the comments configurable, probably should be an option in the configuration file.

Is it OK to use a PAT with the repo permission?

What implications does it have? What can an attacker do when he obtains this token? If he can only

Is a Python webserver acceptable?

Fine by me, otherwise Rust is a good candidate :)

Another solution (a app): https://github.com/probot/mistaken-pull-closer .. We can self-host it if desired: https://github.com/probot/mistaken-pull-closer/blob/master/docs/deploy.md (much less permission compared to a PAT solution)

@jelle

Here is a quick list of our available options (based on my own research and the community's feedback) for the PR auto closure task. I wanted to list pros and cons for each option but I think that is subjective so I will avoid that.

Use GitHub webhooks with a WSGI application. We can monitor the pull_request event for the opened or reopened actions and then close them accordingly and possibly also add an admin comment that can be customizable. Unfortunately the GitHub REST API for editing pull requests does not allow us to lock it only close it. Now since each webhook can be installed on an organization this will work for all our mirrors. It does require a PAT with minimum public_repo access. Things to consider beyond security is the fact that we need a running webserver and a way to avoid rate limit abuse as someone can simply click re-open all the time on the PR.
Use a GitHub action. Note actions operate per repository which means that we will need to copy the action to all mirrors. If we find a way to sync our action to all organization repos not a big deal I guess unless we hate duplication. A bit more work but does not require a webserver or using a PAT since we can take advantage of GITHUB_TOKEN.
A scheduled workflow. According to Kristian

running the workflow on a schedule would require a PAT but we don't need to add a workflow to every mirrored repository.

I feel this might be through templates? According to the documentation:

A workflow template can be used by any repository within the organization

But not sure how/if that can be done automatically. There was also a suggestion that if we go with a timed schedule then maybe we can use GitLab CI instead of GitHub workflows.

Use a GitHub app like pull_closer that seems to allow for finer and safer permissions to the repos. It will require hosting.

I do not mind looking further into any of the options mentioned above (or look for even more options...) but we need to decide how to proceed sooner than later so that we are all in line.

I think a scheduled github action would be the easiest approach here, it does not require any hosting from our part. Unfortunately, github has a limit of 2000 min/month (33 h/month) on github actions (see the documentation). So, we would probably need to run it at something like each 10~30min.

To be clear, this would be running in a single repo, the script that we run would close the open PRs for all organization repos.

If we opt to host our own thing, it would require more overhead from our part. Let me know what we want to do, I would go for the scheduled github action and adapt if it gives us trouble.

I think a scheduled github action would be the easiest approach here, it does not require any hosting from our part.

If we decide to go that route, we should at least consider using Gitlab CI.

Unfortunately, github has a limit of 2000 min/month (33 h/month) on github actions (see the documentation). So, we would probably need to run it at something like each 10~30min.

The doc says:

GitHub Actions usage is free for public repositories. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account.

Hello Filipe, Kristian thank you both for your input.

I guess as I mention above, it makes sense to first decide how to proceed given the available options and then we can look into the desired choice in more detail. We can always start up a discussion if an unexpected issue pops up.

It would also be good to know if anyone else is "actively" working on this issue so that we do not do duplicate work.

I will be happy to look into the proposed solution once @jelle decides how to proceed. If anyone else wants to take over then I will move on to a different task.

Another idea is to (ab)use the interaction limit feature:

The Repository Interactions API allows people with owner or admin access to temporarily restrict which users can comment, open issues, or create pull requests in a public repository. When restrictions are enabled, only the specified group of GitHub users will be able to participate in interactions. Restrictions expire 24 hours from the time they are set. Here's more about the groups of GitHub users:

Existing users: When you limit interactions to existing_users, new users with accounts less than 24 hours old who have not previously contributed and are not collaborators will be temporarily restricted in the respository.

Contributors only: When you limit interactions to contributors_only, users who have not previously contributed and are not collaborators will be temporarily restricted in the respository.

Collaborators only: When you limit interactions to collaborators_only, users who are not collaborators will be temporarily restricted in the respository.

It would require calling the API once a day though.

In the GUI it allows setting it for 6 months now, this is a new change, so we can check if the API docs are just outdated.

@svenstaro @grazzolini @anthraxx I have set interaction limits to "Limit to repository collaborators" for 6 months for our svntogit repositories.

In the GUI it allows setting it for 6 months now, this is a new change, so we can check if the API docs are just outdated.

The API does not have any "time" option, it only allows setting a limit for 24 hours.

Proposal:

Create a GitLab project with a CI pipeline which closes the PRs and trigger it from a webhook (from GitHub).

We would need to store a GitHub PAT token as a CI variable, but we are already doing that for archlinux-docker, so should be fine.

Any objections?

https://docs.gitlab.com/ee/ci/triggers/

PoC created: https://gitlab.archlinux.org/klausenbusk/github-pull-closer, test PR here: https://github.com/klausenbusk/github-pull-closer-test/pull/1

Go/no-go?

"qui tacet consentire videtur"

The project has been moved to https://gitlab.archlinux.org/archlinux/github-pull-closer/, a PAT token created with scope public_repo, the webhook has been added to all read-only mirrored github projects and a MR created with updated instructions for setting up mirroring: !423 (merged).

mentioned in merge request !423 (merged)

mentioned in commit e347c558

closed with merge request !423 (merged)

closed with commit 31a84e05

Provide a bot to close GitHub PRs of read-only mirrors

Child items ...

Activity

Admin message

Provide a bot to close GitHub PRs of read-only mirrors

Activity