I have no idea how the token has been generated for T248387

Presumably we could have CI to expose it the same token as GITHUB_OAUTHTOKEN?

Presumably we could have CI to expose it the same token as GITHUB_OAUTHTOKEN?

No objection. We could remove the purpose from the name (as you suggested) or create one dedicated to our purpose (correctly privileged) - as per findings from @Lucas_Werkmeister_WMDE the permissions repo:status & public_repo should suffice.

To me a general GITHUB_OAUTHTOKEN sounds good, as long as it doesn’t have any sensitive permissions (we probably don’t want to let it push commits, or read private repositories – though hopefully the production secrets aren’t on GitHub at all). A special-purpose variable would also work, of course.

@bd808 @Reedy do you know how the Github token for CI got generated ( T248387#6000432 ) ?

This task is about having an unprivileged token and I assume that is the case of the token that got created. Then we can expose it as both COMPOSER_GITHUB_OAUTHTOKEN and GITHUB_OAUTHTOKEN.

In T254319#6216101, @hashar wrote:

@bd808 @Reedy do you know how the Github token for CI got generated ( T248387#6000432 ) ?

This task is about having an unprivileged token and I assume that is the case of the token that got created. Then we can expose it as both COMPOSER_GITHUB_OAUTHTOKEN and GITHUB_OAUTHTOKEN.

The token belongs to the GitHub account https://github.com/composer-ratelimits-suck. I have the password if you want it.

In T254319#6216101, @hashar wrote:

This task is about having an unprivileged token and I assume that is the case of the token that got created. Then we can expose it as both COMPOSER_GITHUB_OAUTHTOKEN and GITHUB_OAUTHTOKEN.

The token belongs to a completely unprivileged user, so I'd say feel free to expose it wherever it is needed. Probably best not to literally put it in git or on a wiki page, but injecting into Jenkins jobs as an envvar is what I set it up for.