Authenticate gh cli automatically in integrated terminal

[felipecrs]

This is a duplicate of cli/cli#1074. I'm creating it here since the implementation should probably belong here.

The gh cli now supports the environment variable GITHUB_TOKEN for authentication. This extension could expose the GITHUB_TOKEN to the integrated terminal in order to automatically provide authentication for gh cli.

Original text:

VSCode now provides GitHub authentication for git even in its Terminal.

If gh had support for that too, we could have a seamless GitHub Authentication when using gh inside VSCode, which can mainly benefit vscode-dev-containers , Visual Studio Codespaces, and therefore, the upcoming GitHub Codespaces.

[felipecrs]

How about adding a new setting "Export GITHUB_TOKEN to the terminal environment", defaults to false, and users can optionally enable it?

[alexr00]

@TylerLeonhardt I think this is a general GitHub authentication request and not specific to GHPRI.

[TylerLeonhardt]

I don't think this will be possible because we will never know the scopes needed to get the gh CLI working. gh can do pretty much everything that github.com can do which means that it needs pretty much every scope here:
https://github.com/settings/tokens/new

And then once gh adds new functionality with a new scope, then vscode will have to be updated to reflect that. With all that said, I feel as if this could be good as a separate extension for now... just so that we can see how people react. The extension will basically:

• be onStartFinished activated
• ask to sign in (quietly) at the start with basically every scope on that page
• apply the newly acquired GH token to any terminal that gets started (I'm pretty sure this is possible? An extension can add additional env vars to terminals? @Tyriar)

[felipecrs]

I would suggest a different route. I would suggest not to tie this feature to the gh cli, and make it as a new configuration as simple as:

• Inject GITHUB_TOKEN to integrated terminal

This way, not only gh cli would use it, but other tools too. The point is: gh cli is already already to handle tokens without all the different scopes, so that the commands which would require additional scopes fail accordingly.

The main use case for gh cli is the basic workflow: gh repo fork, gh pr checkout, gh pr create and so, which should be pretty much covered by the existing scope which Github Issues and Pull Requests uses.

If the user requires full scope, that user can then either do gh auth login, or set GITHUB_TOKEN by himself.

[TylerLeonhardt]

What's the error when GITHUB_TOKEN isn't permissive enough?

So since GitHub Authentication is only responsible for dishing out GitHub tokens with varying scopes, I think that this work should either be in:

• the GitHub extension that ships in VS Code (is that you @joaomoreno?)
• GHPR extension @alexr00

Both of these ask for similar scopes that cover what @felipecrs wants so extending those to provide this functionality would be easier. Essentially when those extensions get a session, they would then set the environment to include GITHUB_TOKEN with that.

[joaomoreno]

I have concerns about injecting such a powerful token by default, even if behind a setting.

What if the core GitHub extension would contribute a custom terminal Create GitHub terminal or so?

Or, we could generalize this into creating custom terminals with a user-defined arbitrary collection of envs. The user could configure it, give it a name. This would be a feature for Terminals. cc @Tyriar @meganrogge

[felipecrs]

What's the error when GITHUB_TOKEN isn't permissive enough?

I have concerns about injecting such a powerful token by default, even if behind a setting.

Codespaces already does this, by default even.

[Tyriar]

Or, we could generalize this into creating custom terminals with a user-defined arbitrary collection of envs. The user could configure it, give it a name. This would be a feature for Terminals.

Extensions are already able to create profiles, and you can already configure whatever profiles you want as a user. You could for example create a custom profile that points to a separate init script that injects the variable (or just add it to your regular rc file), or just set env on the custom profile in your settings.

@alexr00 this ask belongs to the GHPRI extension imo. I also have concerns about injecting the token and I don't think this should be a feature of core or the GH auth extension, which as @TylerLeonhardt mentioned just hands out tokens, but GHPRI which is the real signal for a user wanting to engage deeply with GH.

I think the opt-in setting with a disclaimer like @felipecrs originally suggested is the way to go? This could be set via the environment variable collection terminal ext API.

[alexr00]

Transferred back to GHPRI.

[felipecrs]

This would still be a very nice to have feature, it would automate setup of GitHub CLI when using Devcontainers (as opposed to have to run gh auth login every time you build a new container).