Can I run gitea actions witout docker?

Im trying to start a gitea actions instance without docker. I registered the gitea act_runner and my demo is the example demo. The doc is unclear on how to do that and I wonder if its possible at all.

name: Gitea Actions Demo
run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
on: [push]

jobs:
  Explore-Gitea-Actions:
    runs-on: fedora
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
      - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
      #- name: Check out repository code
        #uses: actions/checkout@v3
      #- run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ gitea.workspace }}
      - run: echo "🍏 This job's status is ${{ job.status }}."

The thing is; I'm not really comfortable giving sudo root to act_runner as i would have to do sudo act_runner exec here to get this to work as far as I understand.

$  act_runner exec
INFO[0000] Using the only detected workflow event: push 
INFO[0000] Planning jobs for event: push                
INFO[0000] cache handler listens on: http://192.168.1.186:39195 
INFO[0000] Start server on http://192.168.1.186:34567   
[Gitea Actions Demo/Explore-Gitea-Actions] 🚀  Start image=node:16-bullseye
INFO[0000] Parallel tasks (0) below minimum, setting to 1 
[Gitea Actions Demo/Explore-Gitea-Actions]   🐳  docker pull image=node:16-bullseye platform= username= forcePull=false
Error: unable to determine if image already exists for image 'node:16-bullseye' (): permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/node:16-bullseye/json": dial unix /var/run/docker.sock: connect: permission denied

Solution

My well-founded answer is: Yes, gitea actions supports act runner without docker, although with certain restrictions. But there are use cases where the extra layer provided by docker is of no use.

I have an act_runner v0.2.11 on a linux server running. The whole task, for setting it up, required not more than 5-10 minutes.

It is configured with a specific label, that ends with :host. I created a yaml config, pre-filled with all the data that may be used at registration time, and the registration command included the yaml as argument, but also defined --name web_project_onhost --labels "web-project-amd64:host" etc.

sample act_runner_config.yaml

log:
  level: info

runner:
  file: /var/www/vhosts/project.tld/.act-runner/conf/.runner
  capacity: 1
  timeout: 3h
  insecure: true
  fetch_timeout: 5s
  fetch_interval: 2s
  labels:
    - "web-project-amd64:host"

host:
  workdir_parent: /var/www/vhosts/project.tld/act-runner/workdir

cache:
  enabled: true
  dir: "/var/www/vhosts/project.tld/.act-runner/actcache"
  host: ""
  port: 0
  external_server: ""

container:
  network: ""
  privileged: false
  options:
  workdir_parent:
  valid_volumes: []
  docker_host: ""
  force_pull: true
  force_rebuild: false

The runner registration procedure responded this:

INFO Registering runner, arch=amd64, os=linux, version=v0.2.11.
WARN Runner in user-mode.
WARN Labels from command will be ignored, use labels defined in config file.
DEBU Successfully pinged the Gitea instance server
INFO Runner registered successfully.

And in the workflow yaml, you refer to the non-docker runner with its label, but you have to omit the :host .

As you may notice this runner was started by a non-privileged hosting user, it was done by cause, to demonstrate, the use of secrets.

Initially i pasted the whole contents from the .env of a laravel-project into a secret-variable called ENV_TO_DEVEL with the intent, to separate the source deployment, and the sensitive configuration data.

the sample workflow: .gitea/workflows/testing_on_host.yaml

name: Deploy .env with runner
on:
  push:
    branches:
      - devel
    paths:
      - '.gitea/workflows/trigger/deploy.env'

jobs:
  Deploy-DotEnv-To-Devel:
    runs-on: web-project-amd64
    defaults:
      run:
        shell: bash
    steps:
    - name: write secret to dotenv
      run: |
        echo -e "${{ secrets.ENV_TO_DEVEL }}" > /var/www/vhosts/project.tld/devel/.env

Last note: the workflow defines a path to an empty file. To trigger the workflow, this file needs a commit, that gets PUSH-ed to devel branch,and thats it, the action creates an .env with content provided by gitea secrets.