How can I set the git configs user.name and user.email via environment variables

[antnorwe]

I am running code-server in a Kubernetes cluster, and so its entirely possible that the pods hosting it might be recreated at any point. The git config is local and, to the best of my knowledge, not stored in the code-server config. Therefore, if the pod is recreated the git config will be destroyed and I'd have to re-enter it.

Am I missing something? I couldn't find anything in the docs about how to set the Env variables to recreate these configuration items on a rebuild.

[code-asher]

I believe git will take the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables, is that what you mean? They could be set via extraVars.

[antnorwe]

It is, but unfortunately adding those to my manifest didn't work. The env vars are available within the container (echo $GIT_AUTHOR_NAME for example) but after a restart git is still asking me to set the values

[code-asher]

Oh hmm. When you run echo is that from code-server's integrated terminal? And it is the same terminal you are running git commands in? If you see the env vars and git still is not using them in that same terminal session...definitely odd.

I am not sure how to test Kubernetes but I tried running code-server on its own like this:

GIT_AUTHOR_NAME=test GIT_AUTHOR_EMAIL=test@test.com code-server --auth none

And it seems to work in code-server's integrated terminal:

$ printenv GIT_AUTHOR_NAME
test
$ touch hello
$ git add hello
$ git commit -m "test"
[main 3d355d4f7] test
 Author: test <test@test.com>
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 hello

I also tried from the git side panel in the UI and that also worked with the right username.

So maybe there is something wrong with how extraVars works in the Helm chart or something...

[antnorwe]

So although I'm running it in kubernetes, I haven't used the Helm chart - I built a manifest based on the docker compose settings. My manifest is below:

# =========================
# CODE-SERVER
# =========================
apiVersion: apps/v1
kind: Deployment
metadata:
  name: code-server
  namespace: code-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: code-server
  template:
    metadata:
      labels:
        app: code-server
    spec:
      containers:
        - name: code-server
          image: codercom/code-server:4.115.0-39
          ports:
            - containerPort: 8080
              name: http
          env:
            - name: GIT_AUTHOR_NAME
              value: "[name]"
            - name: GIT_AUTHOR_EMAIL
              value: "[email]"
          volumeMounts:
            - name: config
              mountPath: /home/coder/.config
            - name: local
              mountPath: /home/coder/.local
            - name: project
              mountPath: /home/coder/project
      volumes:
        - name: config
          hostPath:
            path: /mnt/k3s/config/code-server
            type: DirectoryOrCreate
        - name: local
          hostPath:
            path: /mnt/k3s/code-server/local
            type: DirectoryOrCreate
        - name: project
          hostPath:
            path: /mnt/scripts
            type: DirectoryOrCreate
---

[code-asher]

Ahh gotcha. Hmm from what little I know that does look correct...

[itxashancode]

I ran into this same thing last year with code-server in Kubernetes. The key insight is that git will respect GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL environment variables when set.

You can set these via code-server's extraVars configuration in your Kubernetes deployment. Here's how:

1. In your code-server values.yaml or config, add:

extraEnv:
 - name: GIT_AUTHOR_NAME
 value: "Your Name"
 - name: GIT_AUTHOR_EMAIL
 value: "your.email@example.com"

2. Or if using Helm directly:

helm install code-server coder/code-server \
 --set extraEnv[0].name=GIT_AUTHOR_NAME \
 --set extraEnv[0].value="Your Name" \
 --set extraEnv[1].name=GIT_AUTHOR_EMAIL \
 --set extraEnv[1].value="your.email@example.com"

This approach works because:

• Git checks these env vars before falling back to local config
• They persist across pod recreations since they're set in the deployment