Send OAuth token to GitHub

[eoger]

has_commit_landed_on_repository doesn't go through github3 and therefore does not enjoy the rate-limiting upgrade provided by our OAuth token.

This should fix the 429 errors seen here.

[coveralls]

Coverage remained the same at 100.0% when pulling 94b41ad on eoger:send-oauth-token-to-gh into 8e97bbd on mozilla-releng:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 268fba1 on eoger:send-oauth-token-to-gh into 8e97bbd on mozilla-releng:master.

[JohanLorenzo]

Thanks a lot for the investigation, Édouard ! I agree with you, has_commit_landed_on_repository() is the function causing trouble.

I tried your fix locally by running:

for i in {1..1000};  do curl --location https://github.com/mozilla/application-services/branch_commits/0a49320a24b2fc826f0153c0627baba1aa94d429 ; done

then

for i in {1..1000};  do curl -H "Authorization: ${A_REAL_TOKEN}" --location https://github.com/mozilla/application-services/branch_commits/0a49320a24b2fc826f0153c0627baba1aa94d429 ; done

I got the same result in both case: after about the same number of requests, Github returned 429. The branch_commit URL is a tricky one: it's not an official API one, so it's not ruled the same way.

As a consequence, I see 2 ways to solve 429:

• either we cache the result of retry_request. Per the logs a single instance already makes 4 requests for a single run. Thus, that would reduce the number of requests by 4.
• or we create a second instance of the beetmover worker so the load is shared between the 2. That's what we have in android-components and that might explain why we haven't seen this issue so far.

The former is the cleanest solution, in my opinion. The latter is easier.

[JohanLorenzo]

In the meantime, a workaround can be to rerun failed tasks.

[JohanLorenzo]

I filed #331 to track the real fix. @MihaiTabara, do you think spinning up a new beetmover instance makes sense?

[eoger]

Work to fix the issue in continuing in #332, thanks for the review @JohanLorenzo !