Improve Config Management/Stateless Runner Deploy Workflows

[benyanke]

Feature Description

Currently, it seems to register a runner, you must fetch a one-time use token.

This is good, when deploying manually. This is not helpful, however, if you're trying to do things like deploy runners with config management or especially a set of runners in an auto scaling group.

I would like an option to allow either 1) reusable registration tokens or 2) some other way to be able to register multiple runners without admin interaction easily.

Screenshots

No response

[techknowlogick]

related: #23643

[lunny]

tokens should be reused, I think maybe we can change the current logic.

[cthu1hoo]

I too ran into this problem while writing my ansible role for runner deployment, reusable tokens (similar to the way gitlab does it) sound like the best approach to me.

[benyanke]

Exactly where I ran into it as well - writing an idiomatic ansible role was almost impossible as-is.

[garymoon]

Woodpecker and Drone accept a symmetic secret via environment variables for both the application and the runners, making automated provisioning zero-touch. Could such a flow be considered for Gitea?

[sebthom]

I don't really understand why a separate token mechanism was implemented for runner registration in the first place. I would suggest to remove it and instead introduce a new scope into the gitea access tokens that allows registering runners, e.g. admin:register_runner or register:runner? This reusable token could then be feed into the act_runner for self-registration. Nice side effect, the token management UI is already there. You see when the token was last used and can easily revoke it.

[sillyguodong]

I would suggest to remove it and instead introduce a new scope into the gitea access tokens that allows registering runners

If you only use PAT to register runners, how do Gitea know the scope level (org, repo, global) of the runners.

[sebthom]

@sillyguodong True, then maybe the Gitea token can be extended to be "fine grained". https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/ instead of adding/maintaining a parallel token infrastructure only for the purpose of runner registration tokens.