[GitHub] List open pull requests for all libraries? [resend]
We need to be able to monitor the open pull requests for all Boost libraries, not just a individual library. I'm not seeing any canned way of doing that via the GitHub web site. Am I missing something? It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this? Thanks, --Beman
On 13 May 2014 14:23, Beman Dawes <bdawes@acm.org> wrote:
It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this?
I think I can create a page on the web site. I'm already using the API to update the super project.
On 13 May 2014 16:09, Daniel James <dnljms@gmail.com> wrote:
On 13 May 2014 14:23, Beman Dawes <bdawes@acm.org> wrote:
It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this?
I think I can create a page on the web site. I'm already using the API to update the super project.
Here's a proof of concept: http://boost.cowic.de/rc/pull_requests.html I'll try to do something more functional soon-ish.
On Tue, May 13, 2014 at 1:38 PM, Daniel James <dnljms@gmail.com> wrote:
On 13 May 2014 16:09, Daniel James <dnljms@gmail.com> wrote:
On 13 May 2014 14:23, Beman Dawes <bdawes@acm.org> wrote:
It does seem possible to access the required information via the GitHub API. Is that the best approach to take? Does anyone know how to do this?
I think I can create a page on the web site. I'm already using the API to update the super project.
Here's a proof of concept:
http://boost.cowic.de/rc/pull_requests.html
I'll try to do something more functional soon-ish. <http://lists.boost.org/mailman/listinfo.cgi/boost>
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted. --Beman
On Tue, May 13, 2014 at 10:41 PM, Beman Dawes <bdawes@acm.org> wrote:
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
I think that added to that, a clear time passed since that date would help realize faster which ones are old.
Klaim - Joël Lamotte wrote:
On Tue, May 13, 2014 at 10:41 PM, Beman Dawes <bdawes@acm.org> wrote:
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
I think that added to that, a clear time passed since that date would help realize faster which ones are old.
Would it be possible to extract the number of comments or even better the time of the lastcomment in the pull request? This would allow to distinguish between no-response and work-in-progress cases to not generate unneeded notifications. Or to made 2-phase notification, warning based on a pull request creation date and alarm based on the time of the last activity. Regards, Adam
On 14 May 2014 11:42, Adam Wulkiewicz <adam.wulkiewicz@gmail.com> wrote:
Klaim - Joël Lamotte wrote:
On Tue, May 13, 2014 at 10:41 PM, Beman Dawes <bdawes@acm.org> wrote:
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
I think that added to that, a clear time passed since that date would help realize faster which ones are old.
Would it be possible to extract the number of comments or even better the time of the lastcomment in the pull request? This would allow to distinguish between no-response and work-in-progress cases to not generate unneeded notifications. Or to made 2-phase notification, warning based on a pull request creation date and alarm based on the time of the last activity.
Yes, but I want to keep the initial version simple. Btw. I've been talking about using the events api, I just realised that the notification api might be easier to use here.
On Tue, May 13, 2014 at 1:41 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, May 13, 2014 at 1:38 PM, Daniel James <dnljms@gmail.com> wrote:
Here's a proof of concept:
http://boost.cowic.de/rc/pull_requests.html
I'll try to do something more functional soon-ish. <http://lists.boost.org/mailman/listinfo.cgi/boost>
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
Seconded: This is very nice. When integrated into boost.org, would this be updated daily or upon each pull request submission and merge? Glen
On May 13, 2014, at 3:18 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Tue, May 13, 2014 at 1:41 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, May 13, 2014 at 1:38 PM, Daniel James <dnljms@gmail.com> wrote:
Here's a proof of concept:
http://boost.cowic.de/rc/pull_requests.html
I'll try to do something more functional soon-ish. <http://lists.boost.org/mailman/listinfo.cgi/boost>
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
Seconded: This is very nice.
When integrated into boost.org, would this be updated daily or upon each pull request submission and merge?
How hard is this page to generate? Is this something that can be generated “on the fly”? (instead of every day/hour/request/whatever)? — Marshall P.S. Very nice.
On 05/14/2014 01:26 AM, Marshall Clow wrote:
On May 13, 2014, at 3:18 PM, Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Tue, May 13, 2014 at 1:41 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, May 13, 2014 at 1:38 PM, Daniel James <dnljms@gmail.com> wrote:
Here's a proof of concept:
http://boost.cowic.de/rc/pull_requests.html
I'll try to do something more functional soon-ish. <http://lists.boost.org/mailman/listinfo.cgi/boost>
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
Seconded: This is very nice.
When integrated into boost.org, would this be updated daily or upon each pull request submission and merge?
How hard is this page to generate? Is this something that can be generated “on the fly”? (instead of every day/hour/request/whatever)?
Quoting: For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour. There's 123 repositories, so if 40 people hit the page within an hour, we're out of the limit. And I would guess if any link it posted to ML, the number of people who will click it will be higher than that. - Volodya
On 14 May 2014 08:31, Vladimir Prus <ghost@cs.msu.su> wrote:
Quoting:
For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour.
There's 123 repositories, so if 40 people hit the page within an hour, we're out of the limit. And I would guess if any link it posted to ML, the number of people who will click it will be higher than that.
I don't think github counts requests when the etag matches, so it's not that bad. But over a 100 checks is still too much to do for every request. It might be possible to do better by using the events api to find out what has updated since the last run, and caching the results to limit how many often that's done.
On 14 May 2014 at 11:31, Vladimir Prus wrote:
How hard is this page to generate? Is this something that can be generated "on the fly"? (instead of every day/hour/request/whatever)?
There's 123 repositories, so if 40 people hit the page within an hour, we're out of the limit. And I would guess if any link it posted to ML, the number of people who will click it will be higher than that.
A varnish reverse proxy would fix that in a cinch. Simply set a TTL of two minutes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 14 May 2014 23:56, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 14 May 2014 at 11:31, Vladimir Prus wrote:
How hard is this page to generate? Is this something that can be generated "on the fly"? (instead of every day/hour/request/whatever)?
There's 123 repositories, so if 40 people hit the page within an hour, we're out of the limit. And I would guess if any link it posted to ML, the number of people who will click it will be higher than that.
A varnish reverse proxy would fix that in a cinch. Simply set a TTL of two minutes.
The response time for requests that aren't cached would be terrible, and it would be likely to fail whenever github is overwhelmed.
On 15 May 2014 at 7:36, Daniel James wrote:
How hard is this page to generate? Is this something that can be generated "on the fly"? (instead of every day/hour/request/whatever)?
There's 123 repositories, so if 40 people hit the page within an hour, we're out of the limit. And I would guess if any link it posted to ML, the number of people who will click it will be higher than that.
A varnish reverse proxy would fix that in a cinch. Simply set a TTL of two minutes.
The response time for requests that aren't cached would be terrible, and it would be likely to fail whenever github is overwhelmed.
I'm not sure why you think that. https://ci.nedprod.com/ comes out of a varnish cache with the actual server sitting behind an OpenVPN in a home residential connection. Ping times are far more awful than they would be with a github API wrap, yet the CI website is perfectly okay to use. varnish knows how to serve stale content when the home DSL dies too. Rather more relevant to these discussions, a list of outstanding pull requests need - with minimal work - not exceed github limits. You can fire and forget. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 13 May 2014 22:18, Glen Fernandes <glen.fernandes@gmail.com> wrote:
On Tue, May 13, 2014 at 1:41 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, May 13, 2014 at 1:38 PM, Daniel James <dnljms@gmail.com> wrote:
Here's a proof of concept:
http://boost.cowic.de/rc/pull_requests.html
I'll try to do something more functional soon-ish. <http://lists.boost.org/mailman/listinfo.cgi/boost>
That's a great start! The one additional piece of information that would be helpful is the date the pull request was submitted.
Seconded: This is very nice.
When integrated into boost.org, would this be updated daily or upon each pull request submission and merge?
Daily at first. But later I will try to use the events api to update individual repos more frequently - although there will still be a bit of a delay.
participants (8)
-
Adam Wulkiewicz -
Beman Dawes -
Daniel James -
Glen Fernandes -
Klaim - Joël Lamotte -
Marshall Clow -
Niall Douglas -
Vladimir Prus