Pagination is not implemented #3
Comments
potiuk
added a commit
to potiuk/periodic-labeler
that referenced
this issue
Jan 4, 2020
Fixes paulfantom#3. Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages. Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs. Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
potiuk
added a commit
to potiuk/periodic-labeler
that referenced
this issue
Jan 4, 2020
Fixes paulfantom#3. Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages. Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs. Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
potiuk
added a commit
to potiuk/periodic-labeler
that referenced
this issue
Jan 4, 2020
Fixes paulfantom#3. Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages. Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs. Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
potiuk
added a commit
to potiuk/periodic-labeler
that referenced
this issue
Jan 4, 2020
Fixes paulfantom#3. Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages. Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs. Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
potiuk
added a commit
to potiuk/periodic-labeler
that referenced
this issue
Jan 4, 2020
Fixes paulfantom#3. Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages. Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs. Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
|
@paulfantom -> Would love to get this merged :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unfortunately most of the Github APIs returning collections returns maximum 30 responses. This is documented here https://developer.github.com/v3/#pagination but unfortunately it is not mentioned in the particular APIs that are affected. So when reading https://developer.github.com/v3/pulls/#list-pull-requests it's not at all obvious that pagination is in operation and that you should add another loop through pages.
Periodic labeler does not have pagination implemented, therefore the result is that in big repositories with > 30 PRs only the OLDEST prs will be checked (that's what is the sorting order). If all those 30 PRs are properly labelled, then the plugin will stop working and will not pick any new PRs. There is an interesting behaviour of that - if there are unlabelled old PRs, they will get updated, so - in fact - they will disappear from the "oldest" list and possibly some new PRs that will be checked in the new pass. However once you have 30 oldest, properly labelled PRs, the plugin stops working. That's really annoying and difficult to detect problem - especially if your repo does not have a lot of PRs.
Pagination is easy. It is described here: https://github.com/google/go-github/#pagination
Pull request with a fix follows shortly.
The text was updated successfully, but these errors were encountered: