search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
43.01k stars 5.31k forks source link

Improve Config Management/Stateless Runner Deploy Workflows #23703

Open benyanke opened 1 year ago

benyanke commented 1 year ago

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 commented 1 year ago

related: https://github.com/go-gitea/gitea/issues/23643

lunny commented 1 year ago

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

cthu1hoo commented 1 year ago

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 commented 1 year ago

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

garymoon commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 8 months ago

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 commented 4 months ago

@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 https://github.com/go-gitea/gitea/pull/24767?

lunny commented 3 months ago

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

KyleGalvin commented 3 months ago

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 commented 1 week ago

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.