Are there any plans to change this? That is so that a runner can run multiple jobs at the same time (concurrently).

It would be really nice, since a lot of the time the jobs are small and don’t require the full machine to run and could run multiple jobs at the same time. Plus most of the time the jobs are spun up in containers so just having fewer runner machines with multiple cpus to spin those up vs having multiple smaller machines or having to run multiple instances of the actions runner service per machine to achieve this…

For more cpu/resource intensive jobs you could select a runner via labels so that it would go onto a machine that is dedicated to that job?

@allir i agree with you man!!!

Thanks @weide-zhou for the details. I think it makes a lot of sense to add these comments into the official documentation.
Before I’ve found this discussion I’ve realized that all our repo workflows share the same default workspace directory on self-hosted runners, and it really made my hair stands on end. I was searching the docs to find out whether it’s actually a problem and there was no answer.

if you want to have multiple runners on the same machine you can run them under different users:

useradd runner1
usermod -a -G docker runner1
usermod -a -G rvm runner1
usermod -a -G wheel runner1
sudo su runner1
cd ~
#from https://github.com/actions/runner/releases
mkdir actions-runner && cd actions-runner
curl -O -L https://github.com/actions/runner/releases/download/v2.296.1/actions-runner-linux-x64-2.296.1.tar.gz
tar xzf ./actions-runner-linux-x64-2.296.1.tar.gz
#from https://github.com/financeit/centah/settings/actions/runners/new?arch=x64&os=linux
./config.sh --url https://github.com/financeit/centah --token ??? --name runner1 --unattended 
sudo ./svc.sh install
sudo ./svc.sh start

+1 for more documentation on parallel workflows.

I set up two Actions Runners under NixOS:

  services.gitea-actions-runner.instances = let
    labels = [
      # From NixOS example config
      # provide a debian base with nodejs for actions
      "debian-latest:docker://node:20-bookworm"
      "debian-bookworm:docker://node:20-bookworm"
      "debian-bullseye:docker://node:20-bullseye"
      # From Gitea example config
      # (see https://gitea.com/gitea/runner-images)
      "ubuntu-latest:docker://gitea/runner-images:ubuntu-latest"
      "ubuntu-22.04:docker://gitea/runner-images:ubuntu-22.04"
      "ubuntu-20.04:docker://gitea/runner-images:ubuntu-20.04"
    ];
    runners = lib.lists.range 0 1;
  in
    builtins.listToAttrs (map (i: {
        name = "runner" + toString i;
        value = {
          enable = true;
          name = "ACME CI amd64 (" + toString i + ")";
          url = "https://10.5.0.11:3000/";
          tokenFile = config.age.secrets.gitea_actions_runner_env.path;
          settings = {
            capacity = 4;
            cache = {
              enabled = true;
              host = "10.5.0.1";
              port = 3088;
            };
          };
          labels = labels;
        };
      })
      runners);

On a single branch they did not become active concurrently. On different branches they did, but only one came up: the workflow includes a MinIO server (Docker image) binding to 0.0.0.0:9000 by default and a collision happens – it seems, the workflows are not fully isolated, even though

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: ""

(https://gitea.com/gitea/act_runner/src/branch/main/internal/pkg/config/config.example.yaml#L63)

I expected each runner to have its own dynamic network by default. 🤔

Further, it was not clear how the cache is being handled in this case. It seemed to work, but each runner used its own cache.

Not critical for my setup so far, all in all in works pretty great already with a single runner! 🙂