-
Notifications
You must be signed in to change notification settings - Fork 49
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
Bors polls too hard #37
Comments
You probably want a real daemon that listens to webhooks. That's basically a rewrite :( |
We've been running into the same issue at Basho. I have a proof-of-concept to simply call bors from the cmd-line when a webhook fires, but unfortunately there are a few issues with this. For one, it's difficult to associate a commit-comment with the associated pull-request. As @brson says, the 'right' solution probably makes bors more stateful. We've already had to move our bors to 12-minute intervals. |
Conditional requests do not count against the rate limit so bors could stay stateless as long as it employs some kind of a persistent cache for the HTTP requests it issues against the GitHub API. |
Rust is on 10 minute intervals now. @jakub- that sounds like the best short-term solution. |
We could also just set-up a local nginx/Varnish proxy that acts as the said cache. |
I looked into using Squid for us at Basho, but had quite a bit of trouble getting it to cache TLS requests to Github. Maybe nginx or Varnish will be easier. I also tried to switch Bors to use httplib2, but ran into an issue there as well. httplib2 offers a persistent cache, and uses conditional requests, as suggested by @jakub-. |
So I'm using the following in nginx: proxy_cache_path /var/data/nginx/cache levels=1:2 keys_zone=cache:50m;
proxy_temp_path /tmp/nginx;
server {
listen 8080;
server_name localhost;
location / {
proxy_cache_bypass "";
proxy_cache cache;
proxy_cache_revalidate on;
proxy_cache_valid any 1s;
proxy_http_version 1.1;
proxy_ignore_headers "Cache-control";
proxy_no_cache "";
proxy_pass https://api.github.com;
}
} and then There's a small issue with this set up, which is that nginx will always serve cached responses that are not older than one second. There doesn't seem to be any way around it as @brson For Rust, if we have an nginx instance with the above running on the same machine as bors, we can switch it to poll as often as we see fit. |
We really should also be verifying the certificate but since the GitHub client we use doesn't, it's a separate issue. |
Rust's bors instance is close to the API rate limit (though I don't have numbers), and already doesn't update fast enough, with a 5 minute polling interval. This situation impresses GitHub support none-to-much when asking for a rate limit increase.
I assume bors will need to be more stateful.
Note that Rust is still running an old version of bors that doesn't incorporate any of the changes from the last six months, so this behavior may be better now, but I don't think so.
The text was updated successfully, but these errors were encountered: