A more robust way to manage act_runner #13188

New Issue

GiteaMirror · 2025-11-02T10:34:13-06:00

GiteaMirror commented

2025-11-02 10:34:13 -06:00

Originally created by @Sharaf5 on GitHub (Jun 21, 2024).

Feature Description

I'm running gitea with act_runner from inside docker
it's perfect : until I tried to use replicas to add more runners for workflows to run in paralel as it's only go for jobs one by one and only run one workflow in a time

I ended with this setup that runs 2 replicas with 2 volumes each for data of each container

services:
...
  gitea-act:
    # image: gitea/act_runner:latest-dind-rootless
    image: gitea/act_runner
    # never use wit replicas
    # container_name: gitea-act
    volumes:
      - ./actions/config.yaml:/config.yaml
      - /data
      # - /var/run/docker.sock:/var/run/docker.sock
      - SOC_DOCKER:/var/run/:delegated
    environment:
      - CONFIG_FILE=/config.yaml
      - GITEA_INSTANCE_URL=http://x.x.x.x/
      - GITEA_HTTP_PORT = 80
      # - GITEA_RUNNER_NAME=xxxxx
      # - GITEA_RUNNER_REGISTRATION_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxx
    networks:
      static:
        ipv4_address: x.x.x.x.
    deploy:
      mode: replicated
      replicas: 2
    depends_on:
      dind:
        condition: service_healthy
      gitea:
        condition: service_started
...

The proplem now is that it doesn't register unless we give it a token
and if so one only will be registed and the other will be rejected

I sugget that runners have some more management like :

accept automaticly from a range of IPs or interface
if runner don't have token, put it in pending state and let the UI user to accept it or reject it - may be useful for k8s
rejected or deleted runners should just delete it's data from database and reject token, rather than blocking the runner itself
refactor the delete event as block event with options to just block runner or ip runner comes from

Screenshots

No response

Originally created by @Sharaf5 on GitHub (Jun 21, 2024). ### Feature Description I'm running `gitea` with `act_runner` from inside docker it's perfect : until I tried to use replicas to add more runners for workflows to run in paralel as it's only go for jobs one by one and only run one workflow in a time ![Screenshot_20240622_014517](https://github.com/go-gitea/gitea/assets/36330265/e95b26b4-df82-46ce-9799-40d787034634) I ended with this setup that runs 2 replicas with 2 volumes each for data of each container ``` services: ... gitea-act: # image: gitea/act_runner:latest-dind-rootless image: gitea/act_runner # never use wit replicas # container_name: gitea-act volumes: - ./actions/config.yaml:/config.yaml - /data # - /var/run/docker.sock:/var/run/docker.sock - SOC_DOCKER:/var/run/:delegated environment: - CONFIG_FILE=/config.yaml - GITEA_INSTANCE_URL=http://x.x.x.x/ - GITEA_HTTP_PORT = 80 # - GITEA_RUNNER_NAME=xxxxx # - GITEA_RUNNER_REGISTRATION_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxx networks: static: ipv4_address: x.x.x.x. deploy: mode: replicated replicas: 2 depends_on: dind: condition: service_healthy gitea: condition: service_started ... ``` The proplem now is that it doesn't register unless we give it a token and if so one only will be registed and the other will be rejected ![Screenshot_20240622_015026](https://github.com/go-gitea/gitea/assets/36330265/7c150211-d4d4-482b-8ff2-decda4655d71) I sugget that runners have some more management like : - [ ] accept automaticly from a range of IPs or interface - [ ] if runner don't have token, put it in pending state and let the UI user to accept it or reject it - may be useful for k8s - [ ] rejected or deleted runners should just delete it's data from database and reject token, rather than blocking the runner itself - [ ] refactor the `delete` event as `block` event with options to just block runner or ip runner comes from ### Screenshots _No response_

GiteaMirror added the type/proposal label 2025-11-02 10:34:13 -06:00

GiteaMirror closed this issue

2025-11-02 10:34:14 -06:00

GiteaMirror commented

2025-11-02 10:34:15 -06:00

@lunny commented on GitHub (Jun 22, 2024):

What's your Gitea version? I think Gitea supports reusing the register token from 1.21.

@lunny commented on GitHub (Jun 22, 2024): What's your Gitea version? I think Gitea supports reusing the register token from 1.21.

GiteaMirror commented

2025-11-02 10:34:15 -06:00

@Sharaf5 commented on GitHub (Jun 22, 2024):

1.22 dockerized
the replica only stops without any errors
I'll check agian for the network

@Sharaf5 commented on GitHub (Jun 22, 2024): 1.22 dockerized the replica only stops without any errors I'll check agian for the network

GiteaMirror commented

2025-11-02 10:34:15 -06:00

@Sharaf5 commented on GitHub (Jun 22, 2024):

Oh I had to use the same local network without one specified ip
turn out the acceptance of the same tocken is not what prevent registeration
I had to comment the ipv4_address field
I should apologize for that
thanks @lunny

but I still have only small set of runner management via the instance
is any of this issue tasks already emplemented or applicable ?

@Sharaf5 commented on GitHub (Jun 22, 2024): Oh I had to use the same local network without one specified ip turn out the acceptance of the same tocken is not what prevent registeration I had to comment the `ipv4_address` field I should apologize for that thanks @lunny but I still have only small set of runner management via the instance is any of this issue tasks already emplemented or applicable ?

GiteaMirror commented

2025-11-02 10:34:15 -06:00

@lunny commented on GitHub (May 8, 2025):

Looks like emplement has been implemented.

@lunny commented on GitHub (May 8, 2025): Looks like emplement has been implemented.

GiteaMirror commented

2025-11-02 10:34:16 -06:00

@Sharaf5 commented on GitHub (May 8, 2025):

yes
It was my fault that I didn't think right from the begining
I used docker volums for the runner identifing file and commented the static custom ip from the container replica then it worked each as a separate worker without issues

@Sharaf5 commented on GitHub (May 8, 2025): yes It was my fault that I didn't think right from the begining I used docker volums for the runner identifing file and commented the static custom ip from the container replica then it worked each as a separate worker without issues

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13188

A more robust way to manage act_runner #13188

Feature Description

Screenshots

A more robust way to manage `act_runner` #13188