You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
act_runner worker
entrypointThe 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
The text was updated successfully, but these errors were encountered: