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.

[nodiscc]

deploy runners with config management

This role can deploy act-runner and register it automatically on a gitea instance. In particular have a look at the registration part [1].

[jtran]

@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.

Wasn't this done in #24767?

[lunny]

I think this has been resolved by #23762 and #27143

[KyleGalvin]

How does this solve the issue in a containerized environment, where we usually just have a single docker command/entrypoint?

It would be really nice to have exactly what @garymoon suggests: inject the secret at startup from the environment. That way the deployment can give both gitea and the runner the same shared key and they can authenticate automatically after that.

No command line. No side channel communication. No post-deploy setup. Just give both the key.

[KyleGalvin]

I was searching for a solution to this, and found myself landing on this same thread 2 months down the line.

I have hacks and workarounds for the time being, but I want to describe my use-case to demonstrate how a shared environment variable between gitea and runners for initial setup can help:

I'm building a helm chart that includes gitea and act runners, and I want to automate the setup between the two.

I believe I could make a sidecar job that connects them using the API, but frankly this approach is more convoluted than I think it should be, and I'm using the following workaround hoping that a better solution comes down the pipeline.

Currently, I install the chart with an empty environment variable for the runner token.

I then wait for gitea to install and generate its own runner token. At this point, the runners are failing due to no valid token.

I go into the UI and copy that token out, pasting it into my chart values.yaml

I then update my helm chart with the new values, at which point the runners stop thrashing and connect.

This process isnt overly complicated for someone who knows how the setup works under the hood, but it would not be easy to point to my helm chart and tell another dev how to setup my environment.