Register act_runner as ephemeral to Gitea

[ChristopherHX]

Feature Description

My idea is to

• add a Ephemeral field to the database structure of the Runner
• when the Ephemeral field is true let FetchTask return no task without error if the assigned task is in progress
• when the Ephemeral field is true let FetchTask return no task with an error if the assigned task is in done, and remove the runner from the database.
• UpdateTask and UpdateLog scope access to runnerid (Done)
• Update the runnerv1 protocol to have an Ephemeral field as well during registration
• Update act_runner to have the ephemeral flag, which implies run-once

This proposal would allow to securely deploy a registred host-mode act_runner in a VM and reset the same after job exit.

Some of my idea has been scetched in https://github.com/ChristopherHX/gitea/tree/ephemeral-runners.

Protocol proposal here: https://gitea.com/gitea/actions-proto-def/pulls/14

Read more here: https://gitea.com/gitea/act_runner/issues/19#issuecomment-932880

Screenshots

No response

[wolfogre]

I have a wait-and-see attitude towards this proposal.

Regarding running safely in host mode, my first instinct is:

• Do not register a new act_runner every time.
• The concurrency of tasks for the registered runner can only be 1, so during the execution of a task, the runner will not fetch a second one. (This is my biggest concern about the proposal; when the runner is not suitable for receiving new tasks, it should not FetchTask, rather than letting the FetchTask function decide whether to assign tasks.)
• When executing tasks, once the execution is successful, do not immediately fetch the next task. Instead, clean up the env or even rebuild the virtual machine.
• When starting a new runner in new env, reuse the local state file of the previously registered runner so that it can be recognized and accepted by Gitea without needing to register again.

---

To clarify, in the current design, Gitea does not actively assign tasks to runners; it only attempts to assign a new task when a runner requests one (if available). The purpose of this design is to allow the runner to decide for itself whether it is ready to receive more tasks, while Gitea only determines if there are new tasks to assign.

[ChristopherHX]

Regarding running safely in host mode, my first instinct is:

This matches with the new run once mode that has been recently merged: https://gitea.com/gitea/act_runner/pulls/598

Anyone can fetch new jobs with the current runner state files, that could be uploaded to a bad actors server when the runner is in host-mode.

The same applies to GitHub Actions as long they are not ephemeral.

My proposal would optionally invalidate the token like in GitHub Actions.

Making FetchTask always fail after a job has been fetched is another idea that depends on once mode of the runner.

[wolfogre]

It cannot be a reason that "#598 has been merged so we should keep going that way." I just want to discuss whether we have a better design to handle this.

[ChristopherHX]

Yes let's discuss, this is still a pure proposal except the hardening change.

I only wanted to clairify the problems of the approuch you have described and that it looks based on my opinion like the once flag.

In GitHub Actions there is an alternative way as well for long lived runner state files

• make the SYSTEM_RUNTIME_TOKEN writeable for logs and task state (GitHub Actions has this as of 2019)
• allow spawning a script that executes a fetched task by pipeing stdio and sent updates directly to gitea (My custom github-act-runner has this, but only GitHub Actions can be used for direct communication)

Adding more native act runtimes, seems to be a mess.