Workflow YAML files are not executed on one Gitea instance #11256

@lunny commented on GitHub (Jul 19, 2023):

podman is not well tested.

@lunny commented on GitHub (Jul 19, 2023): `podman` is not well tested.

GiteaMirror commented

@wolfogre commented on GitHub (Jul 20, 2023):

Have you updated .runner manually? Could you show us the runner list page? It should be https://hosta.domain.tld:9500/admin/actions/runners

@wolfogre commented on GitHub (Jul 20, 2023): Have you updated `.runner` manually? Could you show us the runner list page? It should be `https://hosta.domain.tld:9500/admin/actions/runners`

GiteaMirror commented

@greensquirrel commented on GitHub (Jul 20, 2023):

No, I have not updated the .runner manually. In the .runner above, I have marked the confidential values with hidden.

Here I register a runner on hostA again:
./act_runner register --instance https://hostA.domain.tld:9500 --labels "mylinux" --name MyRunnerOne --no-interactive --token <hidden> -c hostA.yaml

The content of .runner :

{
  "WARNING": "This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.",
  "id": 11,
  "uuid": <hidden>,
  "name": "MyRunnerOne",
  "token": <hidden>
  "address": "https:/hostA.domain.tld:9500",
  "labels": [
    "mylinux",
    "mylinux:host"
  ]
}

See screenshot of the registered runner:

Sadly, if I push a change to my_repo/sandbox_public.git, there is still nothing on the actions page.

Do you know what else I can do?

Can you point me to the source code file where gitea dispatches the actions to the runner? Maybe I can debug statements there.

@greensquirrel commented on GitHub (Jul 20, 2023): No, I have not updated the .runner manually. In the .runner above, I have marked the confidential values with hidden. Here I register a runner on hostA again: ` ./act_runner register --instance https://hostA.domain.tld:9500 --labels "mylinux" --name MyRunnerOne --no-interactive --token <hidden> -c hostA.yaml ` The content of .runner : ``` { "WARNING": "This file is automatically generated by act-runner. Do not edit it manually unless you know what you are doing. Removing this file will cause act runner to re-register as a new runner.", "id": 11, "uuid": <hidden>, "name": "MyRunnerOne", "token": <hidden> "address": "https:/hostA.domain.tld:9500", "labels": [ "mylinux", "mylinux:host" ] } ``` See screenshot of the registered runner: ![runners](https://github.com/go-gitea/gitea/assets/7081996/7e9edbcf-7940-46e9-bed4-0f99e81d6cae) Sadly, if I push a change to my_repo/sandbox_public.git, there is still nothing on the actions page. Do you know what else I can do? Can you point me to the source code file where gitea dispatches the actions to the runner? Maybe I can debug statements there.

GiteaMirror commented

2025-11-02 09:32:29 -06:00

@greensquirrel commented on GitHub (Jul 20, 2023):

podman is not well tested.

Both the working gitea instance and the failing gitea instance run on podman. I don't think that it is a podman issue.

@greensquirrel commented on GitHub (Jul 20, 2023): > `podman` is not well tested. Both the working gitea instance and the failing gitea instance run on podman. I don't think that it is a podman issue.

GiteaMirror commented

@sillyguodong commented on GitHub (Jul 20, 2023):

Can you point me to the source code file where gitea dispatches the actions to the runner? Maybe I can debug statements there.

FetchTask

BTW, it's strange that the runner has two identical labels, could you share your config.yaml (runner.labels is enough)?

@sillyguodong commented on GitHub (Jul 20, 2023): > Can you point me to the source code file where gitea dispatches the actions to the runner? Maybe I can debug statements there. [FetchTask](https://github.com/go-gitea/gitea/blob/cf467119ffa82177258226fd04946a2105ee7aa0/routers/api/actions/runner/runner.go#L128) BTW, it's strange that the runner has two identical labels, could you share your `config.yaml` (`runner.labels` is enough)?

GiteaMirror commented

2025-11-02 09:32:29 -06:00

@greensquirrel commented on GitHub (Jul 20, 2023):

Thank you for the link!

The runner.labels is runner.labels: ["mylinux", "mylinux:host"]

The hostA.yaml in its full glory is shown below:

# Example configuration file, it's safe to copy this as the default config file without any modification.

log:
  # The level of logging, can be trace, debug, info, warn, error, fatal
  level: trace

runner:
  # Where to store the registration result.
  file: .runner
  # Execute how many tasks concurrently at the same time.
  capacity: 1
  # Extra environment variables to run jobs.
  envs:
    A_TEST_ENV_NAME_1: a_test_env_value_1
    A_TEST_ENV_NAME_2: a_test_env_value_2
  # Extra environment variables to run jobs from a file.
  # It will be ignored if it's empty or the file doesn't exist.
  env_file: .env
  # The timeout for a job to be finished.
  # Please note that the Gitea instance also has a timeout (3h by default) for the job.
  # So the job could be stopped by the Gitea instance if it's timeout is shorter than this.
  timeout: 20s
  # Whether skip verifying the TLS certificate of the Gitea instance.
  insecure: true
  # The timeout for fetching the job from the Gitea instance.
  fetch_timeout: 10s
  # The interval for fetching the job from the Gitea instance.
  fetch_interval: 10s
  # The labels of a runner are used to determine which jobs the runner can run, and how to run them.
  # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:16-bullseye", "ubuntu-22.04:docker://node:16-bullseye"]
  # If it's empty when registering, it will ask for inputting labels.
  # If it's empty when execute `deamon`, will use labels in `.runner` file.
  labels: ["mylinux", "mylinux:host"]

cache:
  # Enable cache server to use actions/cache.
  # enabled: true
  enabled: false
  # The directory to store the cache data.
  # If it's empty, the cache data will be stored in $HOME/.cache/actcache.
  dir: ""
  # The host of the cache server.
  # It's not for the address to listen, but the address to connect from job containers.
  # So 0.0.0.0 is a bad choice, leave it empty to detect automatically.
  host: ""
  # The port of the cache server.
  # 0 means to use a random available port.
  port: 0
  # The external cache server URL. Valid only when enable is true.
  # If it's specified, act_runner will use this URL as the ACTIONS_CACHE_URL rather than start a server by itself.
  # The URL should generally end with "/".
  external_server: ""

container:
  # Specifies the network to which the container will connect.
  # Could be host, bridge or the name of a custom network.
  # If it's empty, act_runner will create a network automatically.
  network: ""
  # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker).
  privileged: false
  # And other options to be used when the container is started (eg, --add-host=my.gitea.url:host-gateway).
  options:
  # The parent directory of a job's working directory.
  # If it's empty, /workspace will be used.
  workdir_parent:
  # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob
  # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted.
  # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to:
  # valid_volumes:
  #   - data
  #   - /src/*.json
  # If you want to allow any volume, please use the following configuration:
  # valid_volumes:
  #   - '**'
  valid_volumes: []
  # overrides the docker client host with the specified one.
  # If it's empty, act_runner will find an available docker host automatically.
  # If it's "-", act_runner will find an available docker host automatically, but the docker host won't be mounted to the job containers and service containers.
  # If it's not empty or "-", the specified docker host will be used. An error will be returned if it doesn't work.
  docker_host: ""

host:
  # The parent directory of a job's working directory.
  # If it's empty, $HOME/.cache/act/ will be used.
  workdir_parent:

Do you find anything suspicious setting in there?

@greensquirrel commented on GitHub (Jul 20, 2023): Thank you for the link! The runner.labels is `runner.labels: ["mylinux", "mylinux:host"]` The hostA.yaml in its full glory is shown below: ``` # Example configuration file, it's safe to copy this as the default config file without any modification. log: # The level of logging, can be trace, debug, info, warn, error, fatal level: trace runner: # Where to store the registration result. file: .runner # Execute how many tasks concurrently at the same time. capacity: 1 # Extra environment variables to run jobs. envs: A_TEST_ENV_NAME_1: a_test_env_value_1 A_TEST_ENV_NAME_2: a_test_env_value_2 # Extra environment variables to run jobs from a file. # It will be ignored if it's empty or the file doesn't exist. env_file: .env # The timeout for a job to be finished. # Please note that the Gitea instance also has a timeout (3h by default) for the job. # So the job could be stopped by the Gitea instance if it's timeout is shorter than this. timeout: 20s # Whether skip verifying the TLS certificate of the Gitea instance. insecure: true # The timeout for fetching the job from the Gitea instance. fetch_timeout: 10s # The interval for fetching the job from the Gitea instance. fetch_interval: 10s # The labels of a runner are used to determine which jobs the runner can run, and how to run them. # Like: ["macos-arm64:host", "ubuntu-latest:docker://node:16-bullseye", "ubuntu-22.04:docker://node:16-bullseye"] # If it's empty when registering, it will ask for inputting labels. # If it's empty when execute `deamon`, will use labels in `.runner` file. labels: ["mylinux", "mylinux:host"] cache: # Enable cache server to use actions/cache. # enabled: true enabled: false # The directory to store the cache data. # If it's empty, the cache data will be stored in $HOME/.cache/actcache. dir: "" # The host of the cache server. # It's not for the address to listen, but the address to connect from job containers. # So 0.0.0.0 is a bad choice, leave it empty to detect automatically. host: "" # The port of the cache server. # 0 means to use a random available port. port: 0 # The external cache server URL. Valid only when enable is true. # If it's specified, act_runner will use this URL as the ACTIONS_CACHE_URL rather than start a server by itself. # The URL should generally end with "/". external_server: "" container: # Specifies the network to which the container will connect. # Could be host, bridge or the name of a custom network. # If it's empty, act_runner will create a network automatically. network: "" # Whether to use privileged mode or not when launching task containers (privileged mode is required for Docker-in-Docker). privileged: false # And other options to be used when the container is started (eg, --add-host=my.gitea.url:host-gateway). options: # The parent directory of a job's working directory. # If it's empty, /workspace will be used. workdir_parent: # Volumes (including bind mounts) can be mounted to containers. Glob syntax is supported, see https://github.com/gobwas/glob # You can specify multiple volumes. If the sequence is empty, no volumes can be mounted. # For example, if you only allow containers to mount the `data` volume and all the json files in `/src`, you should change the config to: # valid_volumes: # - data # - /src/*.json # If you want to allow any volume, please use the following configuration: # valid_volumes: # - '**' valid_volumes: [] # overrides the docker client host with the specified one. # If it's empty, act_runner will find an available docker host automatically. # If it's "-", act_runner will find an available docker host automatically, but the docker host won't be mounted to the job containers and service containers. # If it's not empty or "-", the specified docker host will be used. An error will be returned if it doesn't work. docker_host: "" host: # The parent directory of a job's working directory. # If it's empty, $HOME/.cache/act/ will be used. workdir_parent: ``` Do you find anything suspicious setting in there?

GiteaMirror commented

2025-11-02 09:32:29 -06:00

@greensquirrel commented on GitHub (Jul 25, 2023):

The runner has registered as you can see in the screenshot below:

Sadly, the demo.yaml gitea workflow file is never executed on any git push event as seen below. What can be the reason that a gitea workflow yaml file is not executed if an runner is available? Syntax errors in that file are reported by gitea in the web page as far as I understand it.

Maybe the logs help. They look harmless.

2023/07/25 13:57:39 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 42.2ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm)

<Git push happens around here>



2023/07/25 13:57:44 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/my_repo/sandbox_public.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc --advertise-refs .
2023/07/25 13:57:44 ...eb/routing/logger.go:102:func1() [I] router: completed GET /my_repo/Sandbox_public.git/info/refs?service=git-receive-pack for 10.0.2.100:53166, 200 OK in 38.2ms @ repo/http.go:532(repo.GetInfoRefs)
2023/07/25 13:57:44 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/my_repo/sandbox_public.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc /data/git/repositories/my_repo/sandbox_public.git
2023/07/25 13:57:44 ...eb/routing/logger.go:102:func1() [I] router: completed POST /my_repo/Sandbox_public.git/git-receive-pack for 10.0.2.100:53166, 200 OK in 77.0ms @ repo/http.go:500(repo.ServiceReceivePack)
2023/07/25 13:57:49 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 43.7ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm)
2023/07/25 13:57:59 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 42.2ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm)
2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed GET /other/repo.git/info/refs?service=git-upload-pack for 10.0.2.100:53176, 401 Unauthorized in 1.7ms @ repo/http.go:532(repo.GetInfoRefs)
2023/07/25 13:58:00 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/other/repo.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= upload-pack --stateless-rpc --advertise-refs .
2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed GET /other/repo.git/info/refs?service=git-upload-pack for 10.0.2.100:53176, 200 OK in 163.2ms @ repo/http.go:532(repo.GetInfoRefs)
2023/07/25 13:58:00 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/other/repo.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= upload-pack --stateless-rpc /data/git/repositories/other/repo.git
2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed POST /other/repo.git/git-upload-pack for 10.0.2.100:53176, 200 OK in 164.0ms @ repo/http.go:492(repo.ServiceUploadPack)

Here is the content of ./.gitea/workflows/demo.yaml:

name: Gitea Action Demo 1st
run-name: "foobar run-name"
on: [push]
jobs:
  Explore-Gitea-Actions:
    runs-on: mylinux
    steps:
      - run: echo "Hello world! Alpha"

@greensquirrel commented on GitHub (Jul 25, 2023): The runner has registered as you can see in the screenshot below: ![runners](https://github.com/go-gitea/gitea/assets/7081996/1cb94d0e-fe3a-471d-8fb9-ab561c976eb9) Sadly, the demo.yaml gitea workflow file is never executed on any git push event as seen below. What can be the reason that a gitea workflow yaml file is not executed if an runner is available? Syntax errors in that file are reported by gitea in the web page as far as I understand it. ![yaml](https://github.com/go-gitea/gitea/assets/7081996/2e50dd9c-6657-4a84-a9d4-9b3561ef8080) Maybe the logs help. They look harmless. ``` 2023/07/25 13:57:39 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 42.2ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm) <Git push happens around here> 2023/07/25 13:57:44 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/my_repo/sandbox_public.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc --advertise-refs . 2023/07/25 13:57:44 ...eb/routing/logger.go:102:func1() [I] router: completed GET /my_repo/Sandbox_public.git/info/refs?service=git-receive-pack for 10.0.2.100:53166, 200 OK in 38.2ms @ repo/http.go:532(repo.GetInfoRefs) 2023/07/25 13:57:44 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/my_repo/sandbox_public.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= receive-pack --stateless-rpc /data/git/repositories/my_repo/sandbox_public.git 2023/07/25 13:57:44 ...eb/routing/logger.go:102:func1() [I] router: completed POST /my_repo/Sandbox_public.git/git-receive-pack for 10.0.2.100:53166, 200 OK in 77.0ms @ repo/http.go:500(repo.ServiceReceivePack) 2023/07/25 13:57:49 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 43.7ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm) 2023/07/25 13:57:59 ...eb/routing/logger.go:102:func1() [I] router: completed POST /api/actions/runner.v1.RunnerService/FetchTask for 10.0.2.100:53118, 200 OK in 42.2ms @ <autogenerated>:1(http.Handler.ServeHTTP-fm) 2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed GET /other/repo.git/info/refs?service=git-upload-pack for 10.0.2.100:53176, 401 Unauthorized in 1.7ms @ repo/http.go:532(repo.GetInfoRefs) 2023/07/25 13:58:00 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/other/repo.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= upload-pack --stateless-rpc --advertise-refs . 2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed GET /other/repo.git/info/refs?service=git-upload-pack for 10.0.2.100:53176, 200 OK in 163.2ms @ repo/http.go:532(repo.GetInfoRefs) 2023/07/25 13:58:00 ...dules/git/command.go:281:Run() [D] git.Command.RunDir(/data/git/repositories/other/repo.git): /usr/bin/git -c protocol.version=2 -c credential.helper= -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= upload-pack --stateless-rpc /data/git/repositories/other/repo.git 2023/07/25 13:58:00 ...eb/routing/logger.go:102:func1() [I] router: completed POST /other/repo.git/git-upload-pack for 10.0.2.100:53176, 200 OK in 164.0ms @ repo/http.go:492(repo.ServiceUploadPack) ``` Here is the content of ./.gitea/workflows/demo.yaml: ``` name: Gitea Action Demo 1st run-name: "foobar run-name" on: [push] jobs: Explore-Gitea-Actions: runs-on: mylinux steps: - run: echo "Hello world! Alpha" ```

GiteaMirror commented

@lunny commented on GitHub (Jul 26, 2023):

So whether the push will trigger dashboard feed?

@lunny commented on GitHub (Jul 26, 2023): So whether the push will trigger dashboard feed?

GiteaMirror commented

@wolfogre commented on GitHub (Jul 26, 2023):

Even if there is no runner available, you should see the list of runs which are waiting:

If you see nothing, it should mean that the workflow hasn't been triggered. So please check what Lunny said: whether the push will trigger the dashboard feed? Like

@wolfogre commented on GitHub (Jul 26, 2023): Even if there is no runner available, you should see the list of runs which are waiting: ![image](https://github.com/go-gitea/gitea/assets/9418365/c22571f0-df94-48d9-a2f6-c3682b6fad74) If you see nothing, it should mean that the workflow hasn't been triggered. So please check what Lunny said: whether the push will trigger the dashboard feed? Like <img width="824" alt="image" src="https://github.com/go-gitea/gitea/assets/9418365/9a9fe26c-06c0-4f77-9555-b4ebfa336f8f">

GiteaMirror commented

@greensquirrel commented on GitHub (Jul 26, 2023):

Hi @wolfogre

thank you for the screenshots because they show me the normal behaviour!

Concerning your first screenshot: I have no push event listed as you can see in my previous comment: https://github.com/go-gitea/gitea/issues/25949#issuecomment-1649743238
Concerning your second screenshot: Where and what is the dashboard feed? I don't find similar messages in my Gitea Git repo. Below you find a screenshot of my repo homepage (?). Is that the dashboard feed?

@greensquirrel commented on GitHub (Jul 26, 2023): Hi @wolfogre thank you for the screenshots because they show me the normal behaviour! * Concerning your first screenshot: I have no push event listed as you can see in my previous comment: https://github.com/go-gitea/gitea/issues/25949#issuecomment-1649743238 * Concerning your second screenshot: Where and what is the dashboard feed? I don't find similar messages in my Gitea Git repo. Below you find a screenshot of my repo homepage (?). Is that the dashboard feed? ![sandbox_public](https://github.com/go-gitea/gitea/assets/7081996/97f09f4b-acd4-4302-a27b-635179aa875a)

GiteaMirror commented

@sillyguodong commented on GitHub (Jul 26, 2023):

Where and what is the dashboard feed?

It will display in the first page which you will redirect to after login.

@sillyguodong commented on GitHub (Jul 26, 2023): > Where and what is the dashboard feed? It will display in the first page which you will redirect to after login. ![image](https://github.com/go-gitea/gitea/assets/33891828/7a45cebf-b41d-4939-8b06-b3b64b682e29)

GiteaMirror commented

@greensquirrel commented on GitHub (Jul 26, 2023):

Hi @sillyguodong ,

Thank you for your answer!

Sadly, I don't find any trigger on my dashboard. See screenshot below:

What could be the reason for missing push triggers? Do I have to configure anything for it?

@greensquirrel commented on GitHub (Jul 26, 2023): Hi @sillyguodong , Thank you for your answer! Sadly, I don't find any trigger on my dashboard. See screenshot below: ![dashboard](https://github.com/go-gitea/gitea/assets/7081996/19a5cd71-a776-4bca-ba4e-fb4cfe79e910) What could be the reason for missing push triggers? Do I have to configure anything for it?

GiteaMirror commented

@wolfogre commented on GitHub (Jul 27, 2023):

I believe something is going wrong with your instance, please try (not a step-by-step guide, just some rescues I can think of):

(Admin page) Resynchronize pre-receive, update and post-receive hooks of all repositories.
Run command gitea doctor check to check if any problems.
Search logs for errors to see if they is any useful information.
I noticed that your instance seems to be a fresh one, is it possible to reinstall?

@wolfogre commented on GitHub (Jul 27, 2023): I believe something is going wrong with your instance, please try (not a step-by-step guide, just some rescues I can think of): - (Admin page) Resynchronize pre-receive, update and post-receive hooks of all repositories. - <img width="1295" alt="image" src="https://github.com/go-gitea/gitea/assets/9418365/dd9dd4be-0966-4e51-a660-0468aa33e062"> - Run command `gitea doctor check` to check if any problems. - Search logs for errors to see if they is any useful information. - I noticed that your instance seems to be a fresh one, is it possible to reinstall?

GiteaMirror commented

@greensquirrel commented on GitHub (Jul 27, 2023):

Hi @wolfogre

Thanks for your ideas! Sadly, none of your advices were fruitful. Here is the output of gitea doctor check:

89ecdd79d01e:~$ gitea doctor check

[1] Check paths and basic configuration
 - [I] Configuration File Path:    "/data/gitea/conf/app.ini"
 - [I] Repository Root Path:       "/data/git/repositories"
 - [I] Data Root Path:             "/data/gitea"
 - [I] Custom File Root Path:      "/data/gitea"
 - [I] Work directory:             "/data/gitea"
 - [I] Log Root Path:              "/data/gitea/log"
OK

[2] Check Database Version
 - [I] Expected database version: 260
OK

[3] Check if user with wrong type exist
OK

[4] Check if OpenSSH authorized_keys file is up-to-date
OK

[5] Synchronize repo HEADs
 - [I] All 7 repos have their HEADs in the correct state
OK

All done.
89ecdd79d01e:~$

Since my gitea instance runs inside of a container with podman on hostA, I moved the container to two different systems hostB and hostC (OpenSuse and Rocky Linux 9). And on both systems, the actions were running :-) See screenshot below:

The system where my production gitea instance fails runs a CentOS 8. That means that it is highly probably not an Gitea configuration issue since the other systems use the same configuration (except adjustment in the domain names).
Unfortunately, I have to run my production gitea instance on hostA with CentOS 8.

Does anyone know what else to debug? Where is the source code location in Gitea that triggers that an event is appended to the dashboard? Maybe, I can add a logging statement there.

@greensquirrel commented on GitHub (Jul 27, 2023): Hi @wolfogre Thanks for your ideas! Sadly, none of your advices were fruitful. Here is the output of gitea doctor check: ``` 89ecdd79d01e:~$ gitea doctor check [1] Check paths and basic configuration - [I] Configuration File Path: "/data/gitea/conf/app.ini" - [I] Repository Root Path: "/data/git/repositories" - [I] Data Root Path: "/data/gitea" - [I] Custom File Root Path: "/data/gitea" - [I] Work directory: "/data/gitea" - [I] Log Root Path: "/data/gitea/log" OK [2] Check Database Version - [I] Expected database version: 260 OK [3] Check if user with wrong type exist OK [4] Check if OpenSSH authorized_keys file is up-to-date OK [5] Synchronize repo HEADs - [I] All 7 repos have their HEADs in the correct state OK All done. 89ecdd79d01e:~$ ``` Since my gitea instance runs inside of a container with podman on hostA, I moved the container to two different systems hostB and hostC (OpenSuse and Rocky Linux 9). And on both systems, the actions were running :-) See screenshot below: ![dashboard](https://github.com/go-gitea/gitea/assets/7081996/d2ac363f-6c8f-4b49-b9d1-0399ef755cd3) ![actions](https://github.com/go-gitea/gitea/assets/7081996/79836366-7464-4ae7-8818-43fa84bd9eef) The system where my production gitea instance fails runs a CentOS 8. That means that it is highly probably not an Gitea configuration issue since the other systems use the same configuration (except adjustment in the domain names). Unfortunately, I have to run my production gitea instance on hostA with CentOS 8. Does anyone know what else to debug? Where is the source code location in Gitea that triggers that an event is appended to the dashboard? Maybe, I can add a logging statement there.

GiteaMirror commented

@JohnnyZhang0628 commented on GitHub (Aug 10, 2023):

@greensquirrel I have a same question.How do you solve it?

@JohnnyZhang0628 commented on GitHub (Aug 10, 2023): @greensquirrel I have a same question.How do you solve it?

GiteaMirror commented

@greensquirrel commented on GitHub (Aug 10, 2023):

@greensquirrel I have a same question.How do you solve it?

I have not solved it.

Probably, I will solve it by moving away from CentOS 8 to a more recent Linux distribution since that problem only happens on CentOS 8. On which Linux distribution do you have that problem?

@greensquirrel commented on GitHub (Aug 10, 2023): > @greensquirrel I have a same question.How do you solve it? I have not solved it. Probably, I will solve it by moving away from CentOS 8 to a more recent Linux distribution since that problem only happens on CentOS 8. On which Linux distribution do you have that problem?

GiteaMirror commented

@JohnnyZhang0628 commented on GitHub (Aug 10, 2023):

at problem?

@greensquirrel My OS is CentOS7.I Have update gitea 1.19.1 to 1.20.2.I'm not sure if it was an upgrade

@JohnnyZhang0628 commented on GitHub (Aug 10, 2023): > at problem? @greensquirrel My OS is CentOS7.I Have update gitea 1.19.1 to 1.20.2.I'm not sure if it was an upgrade

GiteaMirror commented

@anothaiyoyo commented on GitHub (Aug 11, 2023):

@greensquirrel I just found this problem on Ubuntu 22.04.3 LTS too :(

@anothaiyoyo commented on GitHub (Aug 11, 2023): @greensquirrel I just found this problem on Ubuntu 22.04.3 LTS too :(

GiteaMirror commented

@tf838499 commented on GitHub (Aug 14, 2023):

Hi i faced the same problem but i tried to update my docker version and now it works,
maybe try this solution

@tf838499 commented on GitHub (Aug 14, 2023): Hi i faced the same problem but i tried to update my docker version and now it works, maybe try this solution

GiteaMirror commented

@anothaiyoyo commented on GitHub (Aug 17, 2023):

@tf838499 Hey I just update my docker version and it's worked ! Thank you !

@anothaiyoyo commented on GitHub (Aug 17, 2023): @tf838499 Hey I just update my docker version and it's worked ! Thank you !

GiteaMirror commented

@m90 commented on GitHub (Sep 1, 2023):

I'm encountering the same problem without a good idea how to fix it. My setup:

Gitea (1.20.3) is running in Docker 24 on Ubuntu 22
The act_runner (0.2.5) is running in Docker 24 on Ubuntu 22 as well, on a different host
The runner is successfully registered with the Gitea instance and shown as idling
Actions are enabled for both the Gitea instance as well as the repository
I can see the workflow definitions in the repo's Actions tab
Output of gitea doctor check shows all "OK"s
I resychronized the hooks from the UI
I can see the runner polling the Gitea instance for new jobs every other second

The config file looks like this

name: Test Runner

on: [push]

jobs:
  sleep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Sleep a bit
        run: |
          sleep 300

Yet, no actions are triggered for any commits.

What's strange, and what might be a hint for debugging this is that the runner logs the following when starting up:

time="2023-09-01T09:53:18Z" level=warning msg="Because the Gitea instance is an old version, skip declare labels and version."

Gitea is at 1.20.3 which should be latest if I am not mistaken? The instance went through a few upgrades though, so maybe I missed something in that procedure?

@m90 commented on GitHub (Sep 1, 2023): I'm encountering the same problem without a good idea how to fix it. My setup: - Gitea (1.20.3) is running in Docker 24 on Ubuntu 22 - The act_runner (0.2.5) is running in Docker 24 on Ubuntu 22 as well, on a different host - The runner is successfully registered with the Gitea instance and shown as idling - Actions are enabled for both the Gitea instance as well as the repository - I can see the workflow definitions in the repo's Actions tab - Output of `gitea doctor check` shows all "OK"s - I resychronized the hooks from the UI - I can see the runner polling the Gitea instance for new jobs every other second The config file looks like this ``` name: Test Runner on: [push] jobs: sleep: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Sleep a bit run: | sleep 300 ``` Yet, no actions are triggered for any commits. --- What's strange, and what might be a hint for debugging this is that the runner logs the following when starting up: ``` time="2023-09-01T09:53:18Z" level=warning msg="Because the Gitea instance is an old version, skip declare labels and version." ``` Gitea is at 1.20.3 which should be latest if I am not mistaken? The instance went through a few upgrades though, so maybe I missed something in that procedure?

GiteaMirror commented

@m90 commented on GitHub (Sep 2, 2023):

By now I belive this is due to my Gitea instance not executing any actions on push, i.e. if I configure a webhook to be run on push, this won't happen either. When I manually test the webhook, delivery suceeds, so it's not about bad webhook configuration.

@m90 commented on GitHub (Sep 2, 2023): By now I belive this is due to my Gitea instance not executing any actions on push, i.e. if I configure a webhook to be run on push, this won't happen either. When I manually test the webhook, delivery suceeds, so it's not about bad webhook configuration.

GiteaMirror commented

@techknowlogick commented on GitHub (Sep 2, 2023):

@m90 It could be that the githooks aren't being executed on push event. Could you do three things?

Create a new repo and test if webhooks send from it
Go to the admin dashboard and hit "resynch hooks" and test if webhooks will send on a new push
Check to see if your repos are mounted on a drive that uses "noexec"

@techknowlogick commented on GitHub (Sep 2, 2023): @m90 It could be that the githooks aren't being executed on push event. Could you do three things? 1. Create a new repo and test if webhooks send from it 2. Go to the admin dashboard and hit "resynch hooks" and test if webhooks will send on a new push 3. Check to see if your repos are mounted on a drive that uses "noexec"

GiteaMirror commented