-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add API endpoint to get token for registering runners for repos #23761
Conversation
) | ||
|
||
// GenerateRunnerToken generate a new runner token for a repository. | ||
func GenerateRunnerToken(ctx *context.APIContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any checks to see if Actions are enabled for the instance/org/repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, we should probably check that.
Closes #23643 |
Alternatively, what we could do as well is use one route that decides itself if
|
It's not explicit. A type field is better. |
I could probably re-use the |
// TODO: list runners | ||
// TODO: update runner | ||
// TODO: delete runner | ||
m.Put("/runners", reqToken(auth_model.AccessTokenScopeRepo), reqRepoWriter(unit.TypeActions), repo.GenerateRunnerToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that only write
or even admin
?
// TODO: list runners | ||
// TODO: update runner | ||
// TODO: delete runner | ||
m.Put("/runners", reqToken(auth_model.AccessTokenScopeRepo), reqRepoWriter(unit.TypeActions), repo.GenerateRunnerToken) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, this route should probably be called /runners/new(-registration)-token
or something similar.
) | ||
|
||
// GenerateRunnerToken generate a new runner token for a repository. | ||
func GenerateRunnerToken(ctx *context.APIContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, we should probably check that.
// "404": | ||
// "$ref": "#/responses/notFound" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about additionally returning a 404 or 403 in case actions are disabled?
Rather than having multiple endpoints, and combining this into one endpoint. What should the endpoint be, as /api/v1/actions doesn't exist as a parent, does it makes sense to make it just for runners? |
I think this is a very important feature, especially when using Kubernetes. I had the same problem when I wanted to deploy multiple act_runners.
While this works really well, I'm not entirely happy with the solution. It would be really great if you could register a new act_runner without a token via an API. For security reasons, I think it makes sense to use admin credentials for such a call. This could easily be realized by extending the existing RegisterRequest.
It would also be great if there was a way to unregister act_runner as well, especially if you want them to be created and deleted dynamically, to avoid having unnecessary act_runner corpses in the database. What do you think? |
I mean we can have the type in the API interface, but in fact, stored the tokens like before |
Instead of introducing a new API, wouldn't it be more straight forward to introduce a separate scope into the regular gitea access tokens for registering runners, e.g. Now you have to send a HTTP request to gitea (with a gitea token for auth) just to get a runner registration token. This feels like an unnecessary indirection. |
I've just turned up looking for the ability to register and deregister runners programmatically, great to see conversation and work already happening on it!
my 2c on this (please bare in mind I'm not too familiar yet with the gitea codebase): I'd like for runner tokens to be short lived, and only capable of use for registering a runner at either repo, team, org or global level. The reason for this is that that token is exposed directly to the runner. Using a |
thank you! this is exactly what I needed to fix my problem, even though it would be better if you didn't need to do this amazing work! |
This adds a new route to get a token to register new runners for specific repos
Note: This creates a pattern to create new endpoints for generating runner tokens for orgs and globally (which could be done in other PRs)
Closes #23643
Closes #24750