You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should be using authenticated requests everywhere in CI. Hopefully that isn't a contentious position to take!
Background
There are quite a few instances in this repo where we make HTTP requests to GitHub in a non-authenticated manner. This can lead to rate-limiting, which in turn manifests as flaky failures. The failures tend to be a 403 return code, but if we don't check the return code the failure is more obscure.
This isn't just limited to gh and curl invocations inside of GitHub actions. There are other, less obvious, situations where we are making unauthenticated requests to GitHub too. Examples include: downloading buildpacks from github in integration tests, and downloading jam/pack from github before packaging a buildpack.
Additional thoughts
I don't think we should force humans to use tokens locally, but I do think we should ensure that all scripts/tests/tooling that could be run both locally and in CI have the option to use a token if provided. We have some form of support for this in some places (e.g. running integration tests can set a token that is picked up by freezer) but not in other places (e.g. when installing jam). Ensuring that we are able to use a token, but that we don't have to use it, gives us the best of both worlds - authentication in CI and smooth local development experience.
As a side-bar, I don't love the mechanism for obtaining a token via lastpass. I suspect that as part of this work, we may choose to refactor this to use the GITHUB_TOKEN environment variable in CI, which might lead us to reconsider if storing tokens in lastpass is still the best experience for local users.
The text was updated successfully, but these errors were encountered:
Summary
We should be using authenticated requests everywhere in CI. Hopefully that isn't a contentious position to take!
Background
There are quite a few instances in this repo where we make HTTP requests to GitHub in a non-authenticated manner. This can lead to rate-limiting, which in turn manifests as flaky failures. The failures tend to be a
403
return code, but if we don't check the return code the failure is more obscure.This isn't just limited to
gh
andcurl
invocations inside of GitHub actions. There are other, less obvious, situations where we are making unauthenticated requests to GitHub too. Examples include: downloading buildpacks from github in integration tests, and downloadingjam
/pack
from github before packaging a buildpack.Additional thoughts
I don't think we should force humans to use tokens locally, but I do think we should ensure that all scripts/tests/tooling that could be run both locally and in CI have the option to use a token if provided. We have some form of support for this in some places (e.g. running integration tests can set a token that is picked up by freezer) but not in other places (e.g. when installing jam). Ensuring that we are able to use a token, but that we don't have to use it, gives us the best of both worlds - authentication in CI and smooth local development experience.
As a side-bar, I don't love the mechanism for obtaining a token via lastpass. I suspect that as part of this work, we may choose to refactor this to use the
GITHUB_TOKEN
environment variable in CI, which might lead us to reconsider if storing tokens in lastpass is still the best experience for local users.The text was updated successfully, but these errors were encountered: