Question/Bug: Commit to Git Repo #90

@mbecker20 commented on GitHub (Oct 15, 2024):

Ok, I see this now in your log: fatal: unable to auto-detect email address (got 'root@ubuntu-200.(none)').

It will try to git push using the git config you set on the host. It will only set it for you if it isn't already set.

It looks like the issue here is that you ran git config --global user.email {email}, but the email you provided is invalid. Since Periphery won't change this config after its set (for good reason, it shouldn't change the user config if they need it a certain way), you will have to SSH in and set git config --global user.email {valid_email}, ensuring the email is valid format (it doesn't need to actually exist). The default should work: git config --global user.email "komodo@komo.do".

@mbecker20 commented on GitHub (Oct 15, 2024): Ok, I see this now in your log: `fatal: unable to auto-detect email address (got 'root@ubuntu-200.(none)')`. It will try to `git push` using the `git config` you set on the host. It will only set it for you if it isn't already set. It looks like the issue here is that you ran `git config --global user.email {email}`, but the email you provided is invalid. Since Periphery won't change this config after its set (for good reason, it shouldn't change the user config if they need it a certain way), you will have to SSH in and set `git config --global user.email {valid_email}`, ensuring the email is valid format (it doesn't need to actually exist). The default should work: `git config --global user.email "komodo@komo.do"`.

GiteaMirror commented

@beraj commented on GitHub (Oct 15, 2024):

Thank you for the reply. E-mail format was valid. I tried clearing .gitconfig file on the host but still same. I'll keep playing with it.

@beraj commented on GitHub (Oct 15, 2024): Thank you for the reply. E-mail format was valid. I tried clearing .gitconfig file on the host but still same. I'll keep playing with it.

GiteaMirror commented

@beraj commented on GitHub (Oct 15, 2024):

Interestingly, the commit to the gitea repository works ok for the resource sync to update the toml file. Just seem to be having the issue with stacks. Sorry if it's user error.

@beraj commented on GitHub (Oct 15, 2024): Interestingly, the commit to the gitea repository works ok for the resource sync to update the toml file. Just seem to be having the issue with stacks. Sorry if it's user error.

GiteaMirror commented

@mbecker20 commented on GitHub (Oct 15, 2024):

I was able to reproduce this. It works when Periphery container, or systemd "user" install. Seems like the issue is isolated to the "root" systemd install. I believe this to be a linux user issue, the user that periphery runs as resolves its own git config. I'll keep digging on this and see if I can get a patch out.

@mbecker20 commented on GitHub (Oct 15, 2024): I was able to reproduce this. It works when Periphery container, or systemd "user" install. Seems like the issue is isolated to the "root" systemd install. I believe this to be a linux user issue, the user that periphery runs as resolves its own git config. I'll keep digging on this and see if I can get a patch out.

GiteaMirror commented

@mbecker20 commented on GitHub (Oct 15, 2024):

It works when you change /etc/systemd/system/periphery.service to:

[Unit]
Description=Agent to connect with Komodo Core

[Service]
Environment="HOME=/root"
ExecStart=/bin/sh -lc 'periphery --config-path /etc/komodo/periphery.config.toml'
Restart=on-failure
TimeoutStartSec=0

[Install]
WantedBy=default.target

Just change these contents and save, and run

sudo systemctl daemon-reload && sudo systemctl restart periphery

You can sudo systemctl status periphery to make sure its running, and then try committing again and it should work.

I'll also update the installer, and have this handled by installer for other users.

@mbecker20 commented on GitHub (Oct 15, 2024): It works when you change `/etc/systemd/system/periphery.service` to: ``` [Unit] Description=Agent to connect with Komodo Core [Service] Environment="HOME=/root" ExecStart=/bin/sh -lc 'periphery --config-path /etc/komodo/periphery.config.toml' Restart=on-failure TimeoutStartSec=0 [Install] WantedBy=default.target ``` Just change these contents and save, and run ``` sudo systemctl daemon-reload && sudo systemctl restart periphery ``` You can `sudo systemctl status periphery` to make sure its running, and then try committing again and it should work. I'll also update the installer, and have this handled by installer for other users.

GiteaMirror commented

@beraj commented on GitHub (Oct 15, 2024):

That worked for me! Thank you sir.

@beraj commented on GitHub (Oct 15, 2024): That worked for me! Thank you sir.

GiteaMirror commented

https://github.com/mbecker20/komodo/tree/main/scripts#force-service-file-recreation

@mbecker20 commented on GitHub (Oct 15, 2024):

New installs with the systemd installer will now write the updated service file contents.

Existing installs facing this issue can add the --force-service-file flag to the installer so it updates their existing service file:

curl -sSL https://raw.githubusercontent.com/mbecker20/komodo/main/scripts/setup-periphery.py | python3 --force-service-file

@mbecker20 commented on GitHub (Oct 15, 2024): New installs with the `systemd` installer will now write the updated service file contents. Existing installs facing this issue can add the `--force-service-file` flag to the installer so it updates their existing service file: ``` curl -sSL https://raw.githubusercontent.com/mbecker20/komodo/main/scripts/setup-periphery.py | python3 --force-service-file ``` https://github.com/mbecker20/komodo/tree/main/scripts#force-service-file-recreation

GiteaMirror commented

@FoxxMD commented on GitHub (Oct 17, 2024):

I'm encountering this issue when using the periphery docker image with a non-root user.

  komodo-periphery:
    user: "1000:1000"
    restart: unless-stopped
    image: ghcr.io/mbecker20/periphery:latest
    logging:
      driver: local
    ports:
      - 8120:8120
    volumes:
      - /home/foxx/komodo/stacks:/etc/komodo/stacks
#...

Create a fresh stack in Komodo and non-existent folder in stacks (for the stack)
In Git Repo mode with an existing git provider
Pulls the repository without issue and I can create the stack config
Make a change to compose.yaml in the Info page -> Save -> Commit -> Write Stack Contents fails

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'unknown@1d3413281c85.(none)')

Repeating this process but using root in the container (comment out user: 1000:1000) succeeds without error.

@FoxxMD commented on GitHub (Oct 17, 2024): I'm encountering this issue when using the `periphery` docker image with a **non-root user.** ```yaml komodo-periphery: user: "1000:1000" restart: unless-stopped image: ghcr.io/mbecker20/periphery:latest logging: driver: local ports: - 8120:8120 volumes: - /home/foxx/komodo/stacks:/etc/komodo/stacks #... ``` * Create a fresh stack in Komodo and non-existent folder in stacks (for the stack) * In **Git Repo** mode with an existing git provider * Pulls the repository without issue and I can create the stack config * Make a change to `compose.yaml` in the Info page -> Save -> Commit -> Write Stack Contents fails ``` Author identity unknown *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'unknown@1d3413281c85.(none)') ``` Repeating this process but using root in the container (comment out `user: 1000:1000`) succeeds without error.

GiteaMirror commented

@mbecker20 commented on GitHub (Oct 19, 2024):

@FoxxMD The systemd one started working when a HOME env variable was defined, maybe try creating a custom periphery.Dockerfile for periphery:

# periphery.Dockerfile
FROM ghcr.io/mbecker20/periphery
USER 1000:1000
WORKDIR /home/user
ENV HOME=/home/user

and change the compose file

  komodo-periphery:
    restart: unless-stopped
    # image: ghcr.io/mbecker20/periphery:latest
    build:
      context: .
      dockerfile: periphery.Dockerfile
    logging:
      driver: local
    ports:
      - 8120:8120
    volumes:
      - /home/foxx/komodo/stacks:/etc/komodo/stacks

@mbecker20 commented on GitHub (Oct 19, 2024): @FoxxMD The systemd one started working when a HOME env variable was defined, maybe try creating a custom periphery.Dockerfile for periphery: ```dockerfile # periphery.Dockerfile FROM ghcr.io/mbecker20/periphery USER 1000:1000 WORKDIR /home/user ENV HOME=/home/user ``` and change the compose file ```yaml komodo-periphery: restart: unless-stopped # image: ghcr.io/mbecker20/periphery:latest build: context: . dockerfile: periphery.Dockerfile logging: driver: local ports: - 8120:8120 volumes: - /home/foxx/komodo/stacks:/etc/komodo/stacks ```

GiteaMirror commented

@FoxxMD commented on GitHub (Oct 22, 2024):

The custom dockerfile fixed it! I'll see if I can get this to work with the actual periphery dockerfile in a backwards compatible way.

fyi this does not work:

services:
  komodo-periphery:
    image: ghcr.io/mbecker20/periphery:latest
    user: "1000:1000"
    working_dir: /home/test
    environment:
      HOME: /home/test
# ...

even though it seems equivalent

@FoxxMD commented on GitHub (Oct 22, 2024): The custom dockerfile fixed it! I'll see if I can get this to work with the actual periphery dockerfile in a backwards compatible way. fyi this does not work: ```yaml services: komodo-periphery: image: ghcr.io/mbecker20/periphery:latest user: "1000:1000" working_dir: /home/test environment: HOME: /home/test # ... ``` even though it seems equivalent

GiteaMirror commented

@FoxxMD commented on GitHub (Oct 22, 2024):

It's possible to just inline the custom dockerfile which is a good enough workaround for now, I think.

services:
  komodo-periphery:
    build:
      context: .
      dockerfile_inline: |
        FROM ghcr.io/mbecker20/periphery:latest
        USER 1000:1000
        WORKDIR /home/myUser
        ENV HOME=/home/myUser
    labels:
      komodo.skip: 
    environment:
      DOCKER_HOST: tcp://socket-proxy:2375
    logging:
      driver: local
    # ...

@FoxxMD commented on GitHub (Oct 22, 2024): It's possible to just [inline the custom dockerfile](https://docs.docker.com/reference/compose-file/build/#dockerfile_inline) which is a good enough workaround for now, I think. ```yaml services: komodo-periphery: build: context: . dockerfile_inline: | FROM ghcr.io/mbecker20/periphery:latest USER 1000:1000 WORKDIR /home/myUser ENV HOME=/home/myUser labels: komodo.skip: environment: DOCKER_HOST: tcp://socket-proxy:2375 logging: driver: local # ... ```

GiteaMirror commented

@undaunt commented on GitHub (May 30, 2025):

@FoxxMD In the periphery container as UID 99 (or 1000) I show up as "I have no name!", and echo $HOME is / and echo $WORKDIR is blank. Are you seeing differently? I flipped my periphery off of root due to "dubious permissions" that I keep fighting with on Unraid on owning the share where my repo is.

Thanks!

@undaunt commented on GitHub (May 30, 2025): @FoxxMD In the periphery container as UID 99 (or 1000) I show up as "I have no name!", and `echo $HOME` is `/` and `echo $WORKDIR` is blank. Are you seeing differently? I flipped my periphery off of root due to "dubious permissions" that I keep fighting with on Unraid on owning the share where my repo is. Thanks!

GiteaMirror commented

@FoxxMD commented on GitHub (May 30, 2025):

@undaunt Sorry but I don't run periphery container's as non-root anymore. It's easier to manage root periphery containers in non-root environments rather than the other way around, from my experience.

I do run periphery on unraid though, without issues. Here's what I have for my stack setup (using unraid compose plugin):

services:
  komodo-periphery:
    restart: unless-stopped
    image: ghcr.io/moghtech/komodo-periphery:latest
    logging:
      driver: local
    ports:
      - 8120:8120
    volumes:
      - /mnt/user/appdata/komodo/stacks:/etc/komodo/stacks
    environment:
      # optional, used for prefixing bind mount volume paths in project's compose.yaml
      DOCKER_DATA: /mnt/user/appdata
    labels:
      komodo.skip:
  socket-proxy:
    image: lscr.io/linuxserver/socket-proxy:latest
    environment:
      - ALLOW_START=1
      - ALLOW_STOP=1
      - ALLOW_RESTARTS=1
      - AUTH=1 #optional, enable for pushing builds to registry and increasing pull rate limits
      - BUILD=1 #required to build images
      - COMMIT=0 #optional
      - CONFIGS=0
      - CONTAINERS=1 #required to manage containers
      - DISABLE_IPV6=0
      - DISTRIBUTION=1 #required for image digest and registry info
      - EVENTS=1 #required for core communication
      - EXEC=1 #required for 'exec' into container, future use
      - IMAGES=1 #required to manage images
      - INFO=1
      - NETWORKS=1 #required to manage networks
      - NODES=0
      - PING=1 #required for core communication
      - POST=1 #required for WRITE operations to all other permissions
      - PLUGINS=0 #optional
      - SECRETS=1
      - SERVICES=1 # for future swarm
      - SESSION=0
      - SWARM=1 # for future swarm
      - SYSTEM=1 #optional, enable for system stats in dashboard
      - TASKS=0
      - VERSION=1 #required for core communication
      - VOLUMES=1 #required to manage volumes
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    restart: unless-stopped
    read_only: true
    tmpfs:
      - /run

I don't bind the repos or builds directories because I don't use those on unraid periphery. If you wanted all of them to be persisted you could replace

     # replace this
     # - /mnt/user/appdata/komodo/stacks:/etc/komodo/stacks
     # with this
      -  /mnt/user/appdata/komodo:/etc/komodo

WRT to dubious permissions that you might be getting from the fix common issues unraid plugin (?): Instead of binding into appdata you could use an unassigned device as the mount, or create another share exclusive in a cache pool and use that.

@FoxxMD commented on GitHub (May 30, 2025): @undaunt Sorry but I don't run periphery container's as non-root anymore. It's easier to manage root periphery containers in non-root environments rather than the other way around, from my experience. I do run periphery on unraid though, without issues. Here's what I have for my stack setup (using unraid compose plugin): ```yaml services: komodo-periphery: restart: unless-stopped image: ghcr.io/moghtech/komodo-periphery:latest logging: driver: local ports: - 8120:8120 volumes: - /mnt/user/appdata/komodo/stacks:/etc/komodo/stacks environment: # optional, used for prefixing bind mount volume paths in project's compose.yaml DOCKER_DATA: /mnt/user/appdata labels: komodo.skip: socket-proxy: image: lscr.io/linuxserver/socket-proxy:latest environment: - ALLOW_START=1 - ALLOW_STOP=1 - ALLOW_RESTARTS=1 - AUTH=1 #optional, enable for pushing builds to registry and increasing pull rate limits - BUILD=1 #required to build images - COMMIT=0 #optional - CONFIGS=0 - CONTAINERS=1 #required to manage containers - DISABLE_IPV6=0 - DISTRIBUTION=1 #required for image digest and registry info - EVENTS=1 #required for core communication - EXEC=1 #required for 'exec' into container, future use - IMAGES=1 #required to manage images - INFO=1 - NETWORKS=1 #required to manage networks - NODES=0 - PING=1 #required for core communication - POST=1 #required for WRITE operations to all other permissions - PLUGINS=0 #optional - SECRETS=1 - SERVICES=1 # for future swarm - SESSION=0 - SWARM=1 # for future swarm - SYSTEM=1 #optional, enable for system stats in dashboard - TASKS=0 - VERSION=1 #required for core communication - VOLUMES=1 #required to manage volumes volumes: - /var/run/docker.sock:/var/run/docker.sock:ro restart: unless-stopped read_only: true tmpfs: - /run ``` I don't bind the `repos` or `builds` directories because I don't use those on unraid periphery. If you wanted all of them to be persisted you could replace ```yaml # replace this # - /mnt/user/appdata/komodo/stacks:/etc/komodo/stacks # with this - /mnt/user/appdata/komodo:/etc/komodo ``` WRT to `dubious permissions` that you might be getting from the fix common issues unraid plugin (?): Instead of binding into appdata you could use an unassigned device as the mount, or create another share exclusive in a cache pool and use that.

GiteaMirror commented

@undaunt commented on GitHub (May 30, 2025):

Thanks @FoxxMD

What I've got right now is below. I'm combining your excellent blog with Nick's update cycle by doing a repo git-backed, and then all stacks are file based pointing at that repo in /mnt/user/docker. I then force locate the docker stacks to be outside of Appdata so it matches the bind mount.

Let me look through your compose and keep working on it.

  komodo:
    image: ghcr.io/moghtech/komodo-core:latest
    container_name: komodo
    restart: unless-stopped
    depends_on:
      - komodo-db
    networks:
      - ${PROXY_NETWORK}
      - ${APP_NETWORK}
    volumes:
      - ${APPDATA_DIR}/komodo/repo-cache:/repo-cache
      - ${APPDATA_DIR}/komodo/action-cache:/action-cache
      - ${APPDATA_DIR}/komodo/syncs:/syncs
    environment:
      TZ: ${TZ}
      KOMODO_DATABASE_ADDRESS: komodo-db:27017
      KOMODO_DATABASE_USERNAME: ${KOMODO_DB_USERNAME}
      KOMODO_DATABASE_PASSWORD: ${KOMODO_DB_PASSWORD}
      KOMODO_HOST: https://${SUB_KOMODO}.${DOMAINNAME}
      KOMODO_TITLE: Komodo
      KOMODO_FIRST_SERVER: http://komodo-periphery:8120
      KOMODO_DISABLE_CONFIRM_DIALOG: false
      KOMODO_PASSKEY: ${KOMODO_PASSKEY}
      KOMODO_WEBHOOK_SECRET: ${KOMODO_WEBHOOK_SECRET}
      KOMODO_JWT_SECRET: ${KOMODO_JWT_SECRET}
      KOMODO_LOCAL_AUTH: false
      KOMODO_DISABLE_USER_REGISTRATION: true
      KOMODO_ENABLE_NEW_USERS: false
      KOMODO_DISABLE_NON_ADMIN_CREATE: true
      KOMODO_TRANSPARENT_MODE: false
      KOMODO_OIDC_ENABLED: true
      KOMODO_OIDC_PROVIDER: https://${SUB_POCKET_ID}.${DOMAINNAME}
      KOMODO_OIDC_CLIENT_ID: ${KOMODO_OIDC_CLIENT_ID}
      KOMODO_OIDC_CLIENT_SECRET: ${KOMODO_OIDC_CLIENT_SECRET}
      KOMODO_OIDC_USE_FULL_EMAIL: true
    labels:
      komodo.skip:

  komodo-periphery:
    image: ghcr.io/moghtech/komodo-periphery:latest
    container_name: komodo-periphery
    networks:
      - ${APP_NETWORK}
      - ${SOCKET_NETWORK}
    environment:
      PERIPHERY_ROOT_DIRECTORY: ${APPDATA_DIR}/komodo
      DOCKER_HOST: tcp://socket-proxy:2375
      PERIPHERY_PASSKEYS: ${KOMODO_PASSKEY}
      PERIPHERY_SSL_ENABLED: false
      PERIPHERY_INCLUDE_DISK_MOUNTS: /etc/hostname
    volumes:
      - /proc:/proc
      - ${DOCKER_DIR}:${DOCKER_DIR}
      - ${APPDATA_DIR}/komodo/builds:${APPDATA_DIR}/komodo/builds
      - ${APPDATA_DIR}/komodo/repos:${APPDATA_DIR}/komodo/repos
      - ${APPDATA_DIR}/komodo/stacks:${APPDATA_DIR}/komodo/stacks
    labels:
      komodo.skip:

  komodo-db:
    image: mongo:latest
    container_name: komodo-db
    restart: unless-stopped
    networks:
      - ${APP_NETWORK}
    command: --quiet --wiredTigerCacheSizeGB 0.25
    volumes:
      - ${APPDATA_DIR}/komodo/mongo/configdb:/data/configdb
      - ${APPDATA_DIR}/komodo/mongo/db:/data/db
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${KOMODO_DB_USERNAME}
      MONGO_INITDB_ROOT_PASSWORD: ${KOMODO_DB_PASSWORD}
    labels:
      komodo.skip:

@undaunt commented on GitHub (May 30, 2025): Thanks @FoxxMD What I've got right now is below. I'm combining your excellent blog with Nick's update cycle by doing a repo git-backed, and then all stacks are file based pointing at that repo in `/mnt/user/docker`. I then force locate the docker stacks to be outside of Appdata so it matches the bind mount. Let me look through your compose and keep working on it. ```services: komodo: image: ghcr.io/moghtech/komodo-core:latest container_name: komodo restart: unless-stopped depends_on: - komodo-db networks: - ${PROXY_NETWORK} - ${APP_NETWORK} volumes: - ${APPDATA_DIR}/komodo/repo-cache:/repo-cache - ${APPDATA_DIR}/komodo/action-cache:/action-cache - ${APPDATA_DIR}/komodo/syncs:/syncs environment: TZ: ${TZ} KOMODO_DATABASE_ADDRESS: komodo-db:27017 KOMODO_DATABASE_USERNAME: ${KOMODO_DB_USERNAME} KOMODO_DATABASE_PASSWORD: ${KOMODO_DB_PASSWORD} KOMODO_HOST: https://${SUB_KOMODO}.${DOMAINNAME} KOMODO_TITLE: Komodo KOMODO_FIRST_SERVER: http://komodo-periphery:8120 KOMODO_DISABLE_CONFIRM_DIALOG: false KOMODO_PASSKEY: ${KOMODO_PASSKEY} KOMODO_WEBHOOK_SECRET: ${KOMODO_WEBHOOK_SECRET} KOMODO_JWT_SECRET: ${KOMODO_JWT_SECRET} KOMODO_LOCAL_AUTH: false KOMODO_DISABLE_USER_REGISTRATION: true KOMODO_ENABLE_NEW_USERS: false KOMODO_DISABLE_NON_ADMIN_CREATE: true KOMODO_TRANSPARENT_MODE: false KOMODO_OIDC_ENABLED: true KOMODO_OIDC_PROVIDER: https://${SUB_POCKET_ID}.${DOMAINNAME} KOMODO_OIDC_CLIENT_ID: ${KOMODO_OIDC_CLIENT_ID} KOMODO_OIDC_CLIENT_SECRET: ${KOMODO_OIDC_CLIENT_SECRET} KOMODO_OIDC_USE_FULL_EMAIL: true labels: komodo.skip: komodo-periphery: image: ghcr.io/moghtech/komodo-periphery:latest container_name: komodo-periphery networks: - ${APP_NETWORK} - ${SOCKET_NETWORK} environment: PERIPHERY_ROOT_DIRECTORY: ${APPDATA_DIR}/komodo DOCKER_HOST: tcp://socket-proxy:2375 PERIPHERY_PASSKEYS: ${KOMODO_PASSKEY} PERIPHERY_SSL_ENABLED: false PERIPHERY_INCLUDE_DISK_MOUNTS: /etc/hostname volumes: - /proc:/proc - ${DOCKER_DIR}:${DOCKER_DIR} - ${APPDATA_DIR}/komodo/builds:${APPDATA_DIR}/komodo/builds - ${APPDATA_DIR}/komodo/repos:${APPDATA_DIR}/komodo/repos - ${APPDATA_DIR}/komodo/stacks:${APPDATA_DIR}/komodo/stacks labels: komodo.skip: komodo-db: image: mongo:latest container_name: komodo-db restart: unless-stopped networks: - ${APP_NETWORK} command: --quiet --wiredTigerCacheSizeGB 0.25 volumes: - ${APPDATA_DIR}/komodo/mongo/configdb:/data/configdb - ${APPDATA_DIR}/komodo/mongo/db:/data/db environment: MONGO_INITDB_ROOT_USERNAME: ${KOMODO_DB_USERNAME} MONGO_INITDB_ROOT_PASSWORD: ${KOMODO_DB_PASSWORD} labels: komodo.skip: ```

GiteaMirror commented

@Ashkaan commented on GitHub (Aug 18, 2025):

My setup was working perfectly with 1.18.4, but when I updated to 1.19, this error started happening. How can we fix it?

@Ashkaan commented on GitHub (Aug 18, 2025): My setup was working perfectly with 1.18.4, but when I updated to 1.19, this error started happening. How can we fix it?

GiteaMirror commented

@mbecker20 commented on GitHub (Aug 19, 2025):

@Ashkaan Can you give some more details / logs?

@mbecker20 commented on GitHub (Aug 19, 2025): @Ashkaan Can you give some more details / logs?

GiteaMirror commented

@Ashkaan commented on GitHub (Aug 19, 2025):

Of course! I'm happy to:

File contents to write
Stage 1 of 8
|
0.0 seconds

stdout

name: cloudflare-hermes
services:

  cloudflared:
    image: cloudflare/cloudflared
    container_name: cloudflare
    command: tunnel --metrics 127.0.0.1:60123 --no-autoupdate run --token ${TOKEN}

    networks:
      - cloudflare

    restart: unless-stopped

    healthcheck:
      test: ["CMD", "cloudflared", "tunnel", "--metrics", "127.0.0.1:60123", "ready"]

networks:

  cloudflare:
    name: cloudflare
Set Git Remote
Stage 2 of 8
|
0.0 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git remote set-url origin https://token:<TOKEN>@github.com/Ashkaan/docker
Checkout branch
Stage 3 of 8
|
0.0 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git checkout -f main
stdout

Your branch is up to date with 'origin/main'.
stderr

Already on 'main'
Git pull
Stage 4 of 8
|
0.7 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git pull --rebase --force origin main
stdout

Already up to date.
stderr

From https://github.com/Ashkaan/docker
 * branch            main       -> FETCH_HEAD
Latest Commit
Stage 5 of 8
|
0.0 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git rev-parse --short HEAD && git rev-parse HEAD && git log -1 --pretty=%B
stdout

hash: bb1e3a2
message: Rename cloudflare/.env to cloudflare/hermes/.env
Write File
Stage 6 of 8
|
0.0 seconds

stdout

File written to "/repo-cache/github.com/Ashkaan-docker/main/latest/cloudflare/hermes/compose.yaml"
Add Files
Stage 7 of 8
|
0.0 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git add cloudflare/hermes/compose.yaml
Commit
Stage 8 of 8
|
0.0 seconds

command

cd /repo-cache/github.com/Ashkaan-docker/main/latest && git commit -m "[Komodo] Ashkaan: Write Stack File: update "cloudflare/hermes/compose.yaml""
stderr

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'unknown@995578414e48.(none)')

@Ashkaan commented on GitHub (Aug 19, 2025): Of course! I'm happy to: ``` File contents to write Stage 1 of 8 | 0.0 seconds stdout name: cloudflare-hermes services: cloudflared: image: cloudflare/cloudflared container_name: cloudflare command: tunnel --metrics 127.0.0.1:60123 --no-autoupdate run --token ${TOKEN} networks: - cloudflare restart: unless-stopped healthcheck: test: ["CMD", "cloudflared", "tunnel", "--metrics", "127.0.0.1:60123", "ready"] networks: cloudflare: name: cloudflare Set Git Remote Stage 2 of 8 | 0.0 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git remote set-url origin https://token:<TOKEN>@github.com/Ashkaan/docker Checkout branch Stage 3 of 8 | 0.0 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git checkout -f main stdout Your branch is up to date with 'origin/main'. stderr Already on 'main' Git pull Stage 4 of 8 | 0.7 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git pull --rebase --force origin main stdout Already up to date. stderr From https://github.com/Ashkaan/docker * branch main -> FETCH_HEAD Latest Commit Stage 5 of 8 | 0.0 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git rev-parse --short HEAD && git rev-parse HEAD && git log -1 --pretty=%B stdout hash: bb1e3a2 message: Rename cloudflare/.env to cloudflare/hermes/.env Write File Stage 6 of 8 | 0.0 seconds stdout File written to "/repo-cache/github.com/Ashkaan-docker/main/latest/cloudflare/hermes/compose.yaml" Add Files Stage 7 of 8 | 0.0 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git add cloudflare/hermes/compose.yaml Commit Stage 8 of 8 | 0.0 seconds command cd /repo-cache/github.com/Ashkaan-docker/main/latest && git commit -m "[Komodo] Ashkaan: Write Stack File: update "cloudflare/hermes/compose.yaml"" stderr Author identity unknown *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'unknown@995578414e48.(none)') ```

GiteaMirror commented

@mbecker20 commented on GitHub (Aug 26, 2025):

@Ashkaan The issue is with the git --global config. The change is now being committed from the Core container. I'm not sure why this issue would pop up in your case.

I think if you exec into Core container and run git config --global --get user.email, it will print that bad email. You can manually fix it by running git config --global user.email komodo@komo.do inside core container. But in my experience with fresh Komodos and using it otherwise, I haven't seen this issue before, and since it is reproducible container im not sure what happened here. You can also try just recreating the container and see it that fixes, since this is all stuff inside the container.

@mbecker20 commented on GitHub (Aug 26, 2025): @Ashkaan The issue is with the git --global config. The change is now being committed from the Core container. I'm not sure why this issue would pop up in your case. I think if you exec into Core container and run `git config --global --get user.email`, it will print that bad email. You can manually fix it by running `git config --global user.email komodo@komo.do` inside core container. But in my experience with fresh Komodos and using it otherwise, I haven't seen this issue before, and since it is reproducible container im not sure what happened here. You can also try just recreating the container and see it that fixes, since this is all stuff inside the container. <img width="477" height="87" alt="Image" src="https://github.com/user-attachments/assets/a37fc278-b6c3-4b4e-8393-f588c0f6099a" />

GiteaMirror commented

@Ashkaan commented on GitHub (Aug 26, 2025):

I get a different result with a working 1.18.4 (no response).

Our environment can't handle another outage right now, so I can't test 1.19.1. You mentioned that the change is now being committed. Should we test when 1.19.2 is released?

@Ashkaan commented on GitHub (Aug 26, 2025): I get a different result with a working 1.18.4 (no response). Our environment can't handle another outage right now, so I can't test 1.19.1. You mentioned that the change is now being committed. Should we test when 1.19.2 is released? <img width="893" height="662" alt="Image" src="https://github.com/user-attachments/assets/2862abe6-ba72-439e-a5c5-f9d5e7fb587d" />

GiteaMirror commented