Allow for alternative authentication mechanisms for the Octokit object on construction. about toolkit

[damccorm]

Looking at your linked PR, it looks like your use case is if you don't want to authenticate at all, right? I think I see a use case there, not sure if I see a use case for alternative auth methods - does that seem right?

[josephperrott]

The use case I specifically am running into is needing to authentication with a JWT.

[ericsciple]

I'm not sure whether we need to implement this.

The toolkit class is a thin wrapper convenience function for the common case GITHUB_TOKEN or PAT.

I could see the need if an input accepted a PAT or JWT and a function provided a single abstraction to do the right thing.

Otherwise I would recommend using the Octokit class directly.

Thoughts?

[eine]

IMHO, @actions/github should not duplicate or wrap any of the features provided by @octokit/rest, but extend them. Therefore, authentication and all regular operations should be done with octokit. When a feature from @actions/github is required, it should accept an existing octokit object as an argument. It should not be required for @actions/github to handle authentication at all. For example:

const octokit = new Octokit(getInput('token', { required: false }))
const ghkit = new github.GitHub(octokit)

instead of https://github.com/eine/issue-runner/blob/258088daba8c0e57368d08b2afbc5795cf282490/ts/main.ts#L39-L45

Moreover, it seems that the only addition of https://github.com/actions/toolkit/tree/master/packages/github is that it provides the context for the current action. Wouldn't it be easier if it did just that, instead of being a passthrough for all octokit features?

[ericsciple]

fixed with #314 since the value of github.GitHub expanded to support runner proxy settings

now you can use a different auth mechanism, but still get the proxy settings.