Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatically mirror pull requests on #19607

jugglinmike opened this issue Oct 9, 2019 · 2 comments


Copy link

@jugglinmike jugglinmike commented Oct 9, 2019

We've been building (previously as a replacement for The latter provides two distinct services:

  1. publishing WPT at the latest version of the repository's master branch
  2. publishing a "mirror" of pull requests filed against WPT's project

The first is relatively straightforward, and we completed it without any integration with the WPT repository. The second is more complex, and this issue is intended to facilitate discussion on its implementation.

Our initial implementation is available under the Bocoup GitHub organization and outlined in this presentation. In brief: it's designed to poll the WPT git repository for special refs and create git working trees based on that information. This allows it to function without secrets, trusted access to the git repository, or any configuration in WPT's GitHub project.

We originally planned to create the required git refs from the GitHub "Actions" that ran in response to each pull request. Unfortunately, the feature was subsequently changed in an incompatible way (and we subsequently removed the infrastructure from WPT). We're interested in re-implementing it, and here are some alternatives we're considering:

  1. create the required refs from a dedicated server in response to GitHub "webhook" events
  2. create the required refs from a "scheduled" GitHub Action which identifies relevant pull requests using the GitHub API

The first approach involves granting write permission to an external service, explicit configuration with the WPT GitHub project, and maintaining a secret in an open source project.

The second approach creates noise in the GitHub Actions UI (through many no-op executions), is susceptible to API rate limiting, and will likely result in a less responsive user experience.

Suggestions for other approaches are welcome, although we probably should favor solutions that operate via git refs (since we've already built and deployed a system that works with them).

/cc @foolip @gsnedders @Hexcles @jgraham @sideshowbarker

@jugglinmike jugglinmike added the infra label Oct 9, 2019

This comment has been minimized.

Copy link
Contributor Author

@jugglinmike jugglinmike commented Oct 9, 2019

I'm in favor of the second of the two approaches. The lower responsiveness is only drawback I find concerning, but it's possible that actual delay is acceptable for our use case.


This comment has been minimized.

Copy link

@foolip foolip commented Oct 9, 2019 says these are the current usage limits, subject to change of course:

  • You can execute up to 20 workflows concurrently per repository.
  • You can execute up to 1000 API requests in an hour across all actions within a repository.
  • Each job in a workflow can run for up to 6 hours of execution time.
  • You can run up to 20 jobs concurrently per repository across all workflows.

At best we'd probably use 2 API requests per invocation of a cron action, one to clone the repo and one to query the 100 most recently updated PRs.

Exceeding the limits would break manifest and documentation workflows and be quite bad, but I think the limits are high enough that we can poll every 5 minutes or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.