The prospect wants functionality similar to v1, where a user would link their GitHub/GitLab/BitBucket account, and the SSH key would be added to automate push/pulling.

Spoke with another prospect who would like this + dual-linking functionality, such as we have in Coder Classic:

I wrote some ideas here:

@kylecarbs and I chatted and he also had some ideas about "hooks" that can prompt users to re-validate their tokens even inside a running workspace as well as support for redirecting to arbitrary coder_apps to store tokens. (I'm sure he can expand)

@bpmct can the coder_user_token resource idea you drafted also be made to support short-lived user-to-server access tokens provided by non-OAuth GitHub apps so that customers have that option to avoid the security risks of using GitHub OAuth app tokens which I understand never expire unless explicitly revoked? 🙏

Hey @kconley-sq, we had that in mind when working on the spec 👍🏼

We should also look into how we could support Azure DevOps in this flow

This can be done by integrating with GIT_ASKPASS.

The only problem is that VS Code Remote will override GIT_ASKPASS unless explicitly configured not to do so. We can add "git.useIntegratedAskPass": false to ~/.vscode-server/data/Machine/settings.json, but this is somewhat brittle due to this directory being movable.

Still, I think we should go ahead with the GIT_ASKPASS direction. We'll be able to configure a set of hosts that work with Git to provide credentials, and we can cache them in the agent to reduce state in coderd.

I explored some cases for our GIT_ASKPASS solution to ensure that it covers our bases. It seems like it will, but @bpmct please read through and surface any additional stuff that I missed.

Basic Configuration

We'll add a coder.yaml configuration file. Only git providers will be configurable there, but we should deprecate flags and migrate more after this is merged.

git_providers:
  - match: github.com
    type: github
    client_id: xxxxxx
    client_secret: xxxxxx

GIT_ASKPASS will be set by default inside workspaces. Unfortunately, VS Code overrides this value by default. We'll also edit/create ~/.vscode-server/data/Machine/settings.json with { "git.useIntegratedAskPass": false } to allow our behavior by default.

Using Coder for Git authentication can be disabled per template by explicitly setting the GIT_ASKPASS environment variable to an empty string.

For Kubernetes, we'll add a configuration key which is a string to values.yaml. This is standard for PostgreSQL and other applications. If set, we'll create a ConfigMap that will create a coder.yaml in the pods.

Multiple Providers

Multiple Git Providers is an Enterprise feature.

Multiple GitHub (or other platforms') organizations may be in use on the same Coder deployment. The match property is a regex for this reason, and the first matching provider will be used when authenticating with git.

git_providers:
  - match: github.com\/coder
    client_id: xxxxxx
    client_secret: xxxxxx
  - match: github.com\/cdr
    client_id: xxxxxx
    client_secret: xxxxxx

Matching against a custom path requires enabling useHttpPath in the gitconfig of workspaces. This will not be automated since the gitconfig can be in various places, and touching it sounds risky. Maybe in the future we could run:

git config --global credential.useHttpPath true

Git Provider Support

The git provider configuration provides a type property that indicates the upstream provider. We support the following:

• Azure DevOps
• GitHub
• GitHub Apps
• GitLab
• BitBucket
• OAuth2

An OAuth2 provider exists for supporting less popular Git solutions, like gitea.

git_providers:
  - match: bitbucket.org\/coder
    type: oauth2
    client_id: xxxxxxx
    client_secret: xxxxxxx
    authorize_url: <my-url>/login/oauth/authorize
    access_token_url: <my-url>/login/oauth/access_token

For built-in providers, we simply set the authorize_url, access_token_url, and scope for the user.

Startup Script

This is blocked on #2957. We can make this pretty nice by blocking the execution of the startup script until the user authenticates with Git, but it's awkward to do it right now because the startup script output isn't in the UI.

It would be ideal for displaying the Git hosts required when creating a workspace, and we could make this explicit by configuring it inside an agent:

resource "coder_agent" "dev" {
  git_providers = [
    "github.com"
  ]
}

For this UX, we might want to consider blocking SSH access until the startup script completes... otherwise the user could enter a workspace before they authenticate Git, and be confused why a repository hasn't cloned yet.

# I'm not a fan of this, but it's a start.
resource "coder_agent" "dev" {
  await_startup_script = true
}

Just took a pass, I think this seems will cover all our bases. Kind of unfortunate that setting credential.useHttpPath is necessary for multiple git providers, but it's only a one-time thing that can be in the startup script.

We currently have a gitssh utility that gives the user instructions to add their SSH key to a provider. This may be confusing for developers on a Coder deployment with a self-hosted GitLab provider. Could we rewrite the message to inform the user to use an HTTP origin to clone or even help the auto-auth with GitLab?

GIT_ASKPASS will be set by default inside workspaces. Unfortunately, VS Code overrides this value by default. We'll also edit/create ~/.vscode-server/data/Machine/settings.json with { "git.useIntegratedAskPass": false } to allow our behavior by default.

Is there a simple way to support this for code-server too?

# I'm not a fan of this, but it's a start.
resource "coder_agent" "dev" {
  await_startup_script = true
}

I think this is fine actually. Terraform providers commonly have wait_ conditions, although it is slightly odd it depends on user input. Perhaps on workspace creation, we immediately ask the user to authenticate with all providers so that it's less likely for future builds to be in a "waiting" state?