Feature Description

Currently if act_runner acts as autoscaler it must use the priviledged token with FetchTasks and DeclareRunner permission to update logs, step status etc.

To allow less priviledges in a spawned act_runner for a single fetched Task it makes sense for me to have another token for updating the job and log.

This means for me that act_runner should be extended

• to allow a custom script for creating a vm, kubernetes pod etc.
• to accept a fetchtask json response via stdin (works between windows and wsl, macOS and tart, linux and lxd, linux and bwrap), env, args or pipes (e.g. actions/runner Runner.Worker uses pipes) in a new act_runner worker entrypoint
  • This optional worker cannot fetch jobs as it no longer need the fetchtask token for reporting task state
  • Exits once job is done like run once
  • relevant config.yaml needs to be forwared as well

The benefit of this approuch over ephemeral runners is, we don't need to register a new runner to Gitea each time we create a single job runner

ACTIONS_RUNTIME_TOKEN is already used for artifacts of a particular task and might be a good token for more job scoped permissions without much impact.

Yes I have a workaround by using a http proxy for log and step updates via my custom runner, but beeing able to upload logs directly to gitea is better

Alternative proposal to #32461

Screenshots

No response