rebased: Add Gitea Actions act runner #666
Reference in New Issue
Block a user
No description provided.
Delete Branch "gitea-actions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Please see #596
@vjm Thanks for continuing!
Did you check on all review requests by @justusbunsi in #596?
Did you check this branch on a cluster install of yours?
I've been running the previous codebase fom #596 but I can't get it to work on k8s gitea running on RPI5's for docker build & push.
At that step in the action it fails to connect to dockerd (either through tcp 2376 or unix docker.sock)
Any clues here?
I want to build & push to gitea package manager.
For the act runner I'm using:
gitea/act_runner@0.2.10-dind-rootless
For the dind container I'm using:
docker@dind-rootless
Most other steps I got working; just not push to package manger:
hi @pat-s -- yes, I reviewed and here is where I think we are:
_helpers.tpl
work is completed i believedid i miss anything on this? happy to try and work on this if there is something specific you think we need to address to get this merged.
@Dunky13, i have been running this in my cluster successfully for several weeks with no issues, but not the rootless image. also worth considering whether moving to the buildx builder approach is better than continuing with dind?
Can you try with the root image instead of rootless and see if that works first?
Do you have snippets of your values.yaml and the action for me to recreate? I haven't been able to do so yet :-( I tried multiple root(less) tcp/Unix permutations but unsuccessfully do with buildx
It seems that https://gitea.com/vjm/helm-chart/src/branch/gitea-actions/templates/gitea/act_runner/statefulset.yaml#L46
And L75 are also causing (or are part of) the issue
Sorry for the silence from my side. I am not sure if I can review earlier than this weekend.
@Dunky13
values snippet is very straightforward:
current action:
@Dunky13 hopefully the above helped?
@justusbunsi hopefully the current state of things meets the bar to merge and we can address further enhancements as we go?
@vjm Thanks for continuing the original approach. Please see my comments below.
I consider following topics blocking the PR merge:
_helpers.tpl
I consider following things not really blocking but it helping the Chart integrity and is therefore highly appreciated:
Following things are worth to talk about:
actions.provisioning.token
object in values.yamlhttps://gitea.com/gitea/helm-chart/pulls/596#issuecomment-813114 is still an open issue. If I use the PR changes and run
helm template my-release .
, I get following rendered diff compared to the current main branch:This means, a default Helm release without enabled actions will somewhat modify the app.ini for actions.
Despite that, the given values are not valid in the app.ini structure; see https://docs.gitea.com/administration/config-cheat-sheet#actions-actions for valid options.
If I would add
--set actions.enabled=true
to the above helm command, it should set the following app.ini settings:The
GITEA__INSTANCE__URL
environment variable is actuallyGITEA_INSTANCE_URL
and only valid withintemplates/gitea/act_runner/statefulset.yaml
.fixed!
We should allow customization via
actions.provisioning.ttlSecondsAfterFinished
done!
I am not fully sure, but are we able to wait with provisioning activity via Helm Chart hook mechanism? Instead of waiting for eternity? Or would that confuse tools like ArgoCD?
I imagine a flow like below:
i just tried to test this out and i had some issues -- the post-install hook waited to be applied as expected, but the gitea application was still not ready, even though helm and kubernetes had marked it as ready -- this might still be possible but i'd prefer to push this to a separate PR if possible.
Please move this hard-coded image/tag reference into
values.yaml
. That way users can customize, and we can properly let Renovate update it.done!
I guess we could reuse the already configured
LOCAL_ROOT_URL
from app.ini rendering above?fixed!
This block shouldn't be necessary.
removed!
This block shouldn't be necessary.
removed!
This block shouldn't be necessary.
removed!
This block shouldn't be necessary.
removed!
We should also ensure the content of the ConfigMap is correct.
added unit tests!
@ -410,17 +409,12 @@ actions:
repository: docker
tag: 25.0.2-dind
Do we really need the
actions.provisioning.token
object? Isn't the crafted image reference identical to what{{ include "gitea.image" . }}
from_helpers.tpl
would already provide?removed!
I am hoping to pick this back up this week! FYI.
@justusbunsi -- i think we're ready to merge!
could we merge this and talk separately about the Helm Chart Hook mechanism vs. while-sleep loop? i wasn't able to get it working quickly per my other comment.
REDACTED.... I answered my own question... You're using DinD configuration so that runner can run build jobs for images, and other similar container based actions.
@vjm Thanks for the follow-up. I am not able to re-review until weekend due to time constraints.
Regarding hook mechanism vs. sleep loop: I have nothing against addressing that in another PR.
By the way, anyone else having issues running the recent dind images on containerd? For me, the last working image is 23.x.x-dind. I always had to modify the values to test it locally. Any tips from those following this PR?
I actually have been using buildx instead of the dind, but i purposely did not remove dind in case others still want that approach. see my example action above for the buildx approach!
hi @justusbunsi , just nudging this to make sure we review before it becomes out of date!
I've been eyeing at this PR for months. Is it moving forward or should I just copy the templates manually now.
@vjm Apologies for not reacting earlier, and thanks for nudging 🙂. I'll review tomorrow as for today, I have no brain energy left after work. If it is in a functioning state I won't block a merge.
@DominicMCN, that's no helpful comment. I am aware that this is highly requested. But sometimes real life exists. Keep in mind that we all do this in our spare time. Next time, maybe ask how you can help or test changes in your environment to confirm it from your perspective. The larger the feedback pool, the better.
Hi! I'm a relatively new user myself, and I already have Gitea deployed via Helm chart in my homelab RKE2 cluster, and I decided to test this branch out. I have a few notes, but I will preface this by saying I don't think any of these necessarily block a merge, but may warrant subsequent PRs.
.Values.config.server.LOCAL_ROOT_URL
not explicitly specified in my values file, I got a blank GITEA_INSTANCE_URL which prevented the StatefulSet from starting up.Values.actions.provisioning.enabled
istrue
, so I wasn't able to test out automated provisioning.Values.actions.persistence
Overall though this works great, I was able to manually create a Secret with a manually generated token and my new runner works like a charm!
Thanks for your feedback.
I am currently reviewing it and provide a git patch for the author to be applied. Thanks for confirming the
LOCAL_ROOT_URL
issue.The
volumeClaimTemplate
inStatefulSet
is a requirement from Kubernetes. Without such claim template, the resource would not be valid.Regarding replicas in StatefulSet: Let's first get this over the finish line and collect some user insights how stable it is. Replica > 1 would probably mean mutliple register tokens...
@vjm Unfortunately, the PR was not in a functioning state. Please review below diff and consider applying it.
It fixes several issues with overwriting settings, preserving default behavior, ensures configuration consistency for
actions.*
settings, adds many unittests.With these changes, no Chart user should be able to apply a release with incompatible values. To everyone following this PR: If I missed something, let us know.
📢 EXPAND ME to see my proposed git diff
When I tested this, it worked fine by manually updating the replica count after I deployed it. I changed the PV to RWX by defining it in my values.yaml. Just as a warning to future readers, there was a significant performance impact when adding multiple runners. That performance hit has nothing to do with the helm chart. :)
Hi again! One more minor thing I'm noticing: When the Pod restarts, intermittently there will be several errors/restarts due to dind not yet being completely initialized. You might consider adding a check to ensure the docker daemon is reachable before the runner comes online. Offhand I'm not exactly sure what that would look like.
Recently I configured a gitea instance with an act runner. I looked into this PR for inspiration but I found the token management very complicated.
After fiddling with gitea for a while, I came up with a simpler alternative. Perhaps it is not as robust as the one proposed in this PR, but I will leave the idea here just in case.
The overall idea is very similar to this PR. Before creating the act runner, we create an initContainer that spins up a temporary gitea container, generate a token and save it inside the act runner volume. The temporary gitea container is created on the fly by attaching the main gitea storage as
readOnly
and using a patched gitea configuration file. TheLOCAL_ROOT_URL
setting makes gitea cli connect to an already running instance athttp://<gitea-domain>:<gitea-port>/
to obtain the token. Why is it necessary to obtain the token from an already running instance? Because if we use sqlite on a RWO filesystem, only one instance can be running at a time, and we don't want to kill the main instance.The full act runner recipe can be found in https://gitea.com/gitea/act_runner/issues/280#issuecomment-898726.
I just applied this patch, merged the latest from
main
-- it looks like this is a good patch @justusbunsi !I will continue to test in day to day usage in my cluster, but this looks good to merge to me.
Awesome. Thanks for applying the patch and updating the branch. I'll do my very best giving it a final check today or tomorrow.
@justusbunsi, this is still good to merge, just upgraded the act runner image tag: https://gitea.com/gitea/act_runner/releases/tag/v0.2.11
Ok, this obviously didn't make out. My apologies for not letting you know. 😅
I have now re-reviewed the changes. This PR is good to merge as-is. Will merge it in a second...
Thank you again @vjm for your commitment to get this Pull Request over the finish line. Highly appreciate it.
(I posted this with https://gitea.com/gitea/helm-chart/pulls/666#issuecomment-844643 some time ago) For me, this is still an issue. I did some research and for whatever reason I have to add
DOCKER_IPTABLES_LEGACY=1
as environment variable for thedind
image1. Don't know what's the issue on my side. But I seem not the only person having these issues.So I am merging this PR now, then implement a way to allow custom envs for the
dind
image. Which makes it more flexible for different environments.After that, I'll create a release so that all of you can use this long-awaited Chart feature.
https://github.com/docker-library/docker/issues/463#issuecomment-1881909456 ↩︎
🚀
Released as https://gitea.com/gitea/helm-chart/releases/tag/v10.6.0