Gitea Actions label maps to host vs docker (wrong execution mode) in CI

By Kaveh Alemi·Latchkey

An act_runner label mapping ends in either :host (run directly on the runner host) or :docker://image (run in a container). Choosing the wrong suffix runs the job in the wrong environment, so tools are missing or state leaks between jobs.

What this error means

Jobs behave unexpectedly: a :host label misses tools the container had, or a :docker:// label cannot see host-installed software. Nothing errors on registration, but jobs run in the wrong place.

# host mode: no container isolation, uses host binaries
--labels ubuntu-latest:host
# docker mode: runs inside the named image
--labels ubuntu-latest:docker://node:20-bookworm

Common causes

The label uses :host when a container was intended

A :host mapping runs steps directly on the runner machine, so the container image and its tools are never used.

The label uses docker:// when host tools were needed

A :docker:// mapping isolates the job in a container that may lack software installed on the host.

How to fix it

Set the mapping suffix to the mode you want

1. Decide whether the job should run on the host or in a container.
2. Register the label with :host or :docker://image accordingly.
3. Restart the runner and re-run to confirm the execution mode.

# container mode with a specific image:
--labels ci:docker://node:20-bookworm
# host mode (uses the runner host directly):
--labels ci:host

Keep host and docker labels distinct

Register separate labels for host and docker execution so workflows opt into the right one via runs-on.

--labels host-runner:host,docker-runner:docker://ubuntu:22.04

How to prevent it

• Name labels so their execution mode is obvious.
• Prefer docker mode for reproducible, isolated jobs.
• Reserve host mode for jobs that truly need host access.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions