praise: nice unit test!

Does this work on Windows?

It's admittedly a bit janky, but it does work, because we're passing the literal string ~/.gitconfig from the agent regardless of OS.

I guess it would be a bit cleaner (though more verbose) to turn configPath into an object that directly indicates whether it's absolute or relative to the home dir.

I'm not convinced we should be touching anything in the user's home directory like this. I'd be in favor of removing these variables and exposing owner_email as a variable in the Terraform. These variables are easy to templatize anyways, and I think this could have unexpected consequences.

That's a fair point. So are you suggesting putting something like this into the Terraform startup script?

git config --global user.name ${data.coder_workspace.me.owner}
git config --global user.email ${data.coder_workspace.me.owner_email}

One of the goals discussed in #2665 was to make this continue to work "automatically", but if it's handled by a short, easy-to-paste snippet that we put in our example templates, that's probably just as good.

I agree with @kylecarbs that we probably shouldn't touch this file. For instance, this would break the use-case where a user stores their git config in $XDG_CONFIG_HOME/git/config (usually ~/.config/git/config) since ~/.gitconfig takes precedence, the user might not realize why their config is being ignored. It would be possible to detect the presence of ~/.config/git/config, but $XDG_CONFIG_HOME/git/config requires evaluation of the users dotfiles (e.g. launching a login shell and outputting the value).

Regarding adding git config --global user.name ${data.coder_workspace.me.owner} to the TF startup script, that could also suffer the same problem. If done like this, ideally it would be done in a step where the users environment is respected.

It's unfortunate the env variables can't be used as fallback, they have the benefit of being outside the users configuration.

Would be nice if we had the startup scripts/tasks in the terraform file that run after the agent starts. The git setup could be a configurable task rather than special thing we always run.

I think it'd be nice if we could specify task order, and checking out dotfiles would be part of this task order. Every task would run in the users full shell environment (e.g. login shell), then exit.

For instance:

1. bash -l 'checkout dotfiles; ./dotfiles/setup'
2. zsh -l 'git config --global user.name ...'
3. ...

The bash -l part would be inferred from e.g. /etc/passwd (or some more robust method), this is because the users dotfiles might change the default shell between executions. So dotfiles are checked out as bash, but git config is run as zsh.

@mafredri I'm proposing a template author adds their own environment variables:

resource "coder_agent" "testing" {
  env {
    GIT_AUTHOR_NAME = "${data.coder_workspace.me.owner_name}"
    GIT_AUTHOR_EMAIL = "${data.coder_workspace.me.owner_email}"
  }
}

This can just be a note in our docs for guidance.