Bitbucket API currently broken, doesn't respect start/limit params, breaks '-f' option

[jeffwidman]

Reported here: #20 (comment)

the problem with -f comes from Bitbucket's api that are broken, neither "start" nor "limit" work according to the docs. With 17 issues, if I pass -f 15 it copies the first 2 (=17-15) issues. Similarly, limit does not limit anything but it just takes the last X issues

@serviceman do you know if this is still an issue?

I saw bitbucket rolled out v2 of their cloud apis--would switching to those fix this?

[linuxbandit]

I think I had tried with the "up-to-date" API (v2), and I was very surprised that the docs were really wrong. Surprised that it came from their side, Instead of me mistaking the docs with the API version. But again, that's all I remember: my big surprise, maybe things are different now and I didn't have time to try

[jeffwidman]

Thanks--that is helpful since I was thinking that switching to v2 was the right move because that's where BB would be investing their time to fix stuff... I'll keep an eye on it from time to time and see if they fix it.

A quick google search turns up this issue, but it references v1, not v2: https://answers.atlassian.com/questions/202917/bitbucket-rest-api-request-with-parameters-limit-start-not-worked-properly

[jeffwidman]

I looked into this a bit, v1 supports the following url structure:
https://bitbucket.org/api/1.0/repositories/zzzeek/sqlalchemy/issues/?sort=local_id&start=1000
as documented here: https://confluence.atlassian.com/bitbucket/issues-resource-296095191.html#issuesResource-DELETEanissue
and the offset works.

So all we need to do is add the sort=local_id

I also checked v2 of the BB API and couldn't find an equivalent start param that starts from an ID. We could just iterate through the BB issues and silently drop any with an ID before the start ID before submitting to Github.

See also comments on #30 about page-by-page vs issue-by-issue queries.