rebased: Add Gitea Actions act runner #666
Assignees 
42wim 
6543 
a1012112796 
Akkuman 
appleboy 
axifive 
betacat0 
blumia 
bwko 
caicandong 
ChristopherHX 
DaanSelen 
davidsvantesson 
delvh 
denyskon 
fuxiaohei 
gary-kim 
garymoon 
giteabot 
guillep2k 
HesterG 
hiifong 
jaqra 
jolheiser 
jonasfranz 
jpraet 
kdumontnu 
kemzeb 
kerwin612 
khmarbaise 
KN4CK3R 
kolaente 
lafriks 
lng2020 
lotherk 
luhahn 
lunny 
mrsdizzie 
noerw 
pat-s 
puni9869 
renovate-bot 
richmahn 
rossigee 
sapk 
screenshots 
sillyguodong 
silverwind 
smartclip_tim 
strk 
tboerger 
techknowlogick 
TheFox0x7 
tobiasbp 
typeless 
volker.raschek 
wolfogre 
wxiaoguang 
yardenshoham 
yp05327 
zeripath 
Zettat123
Clear assignees
42wim 6543 a1012112796 Akkuman appleboy axifive betacat0 blumia bwko caicandong ChristopherHX DaanSelen davidsvantesson delvh denyskon fuxiaohei gary-kim garymoon giteabot guillep2k HesterG hiifong jaqra jolheiser jonasfranz jpraet kdumontnu kemzeb kerwin612 khmarbaise KN4CK3R kolaente lafriks lng2020 lotherk luhahn lunny mrsdizzie noerw pat-s puni9869 renovate-bot richmahn rossigee sapk screenshots sillyguodong silverwind smartclip_tim strk tboerger techknowlogick TheFox0x7 tobiasbp typeless volker.raschek wolfogre wxiaoguang yardenshoham yp05327 zeripath Zettat123 No Assignees
Notifications
Due Date No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-gitea#666
Reference in New Issue
Block a user
No description provided.
Delete Branch "vjm/helm-chart: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-rootlessFor the dind container I'm using:
docker@dind-rootlessMost 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.tplwork 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?
9c67c12b4bto36a86fd32fDo 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.tplI 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.tokenobject in values.yaml@@ -301,6 +325,15 @@ https{{- if not .Values.gitea.config.indexer.ISSUE_INDEXER_TYPE -}}{{- $_ := set .Values.gitea.config.indexer "ISSUE_INDEXER_TYPE" "db" -}}{{- end -}}{{- if not .Values.gitea.config.actions.GITEA__ACTIONS__ENABLED -}}gitea/helm-chart#596 (comment) 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=trueto the above helm command, it should set the following app.ini settings:The
GITEA__INSTANCE__URLenvironment variable is actuallyGITEA_INSTANCE_URLand only valid withintemplates/gitea/act_runner/statefulset.yaml.fixed!
@@ -0,0 +20,4 @@{{- toYaml . | nindent 4 }}{{- end }}spec:ttlSecondsAfterFinished: 300We should allow customization via
actions.provisioning.ttlSecondsAfterFinisheddone!
@@ -0,0 +38,4 @@- -c- |while ! nc -z {{ include "gitea.fullname" . }}-http {{ .Values.service.http.port }}; dosleep 5I 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.
@@ -0,0 +28,4 @@spec:initContainers:- name: init-giteaimage: busybox:1.36.1Please move this hard-coded image/tag reference into
values.yaml. That way users can customize, and we can properly let Renovate update it.done!
@@ -0,0 +54,4 @@name: "{{ .Values.actions.existingSecret | default $secretName }}"key: "{{ .Values.actions.existingSecretKey | default "token" }}"- name: GITEA_INSTANCE_URLvalue: "http://{{ include "gitea.fullname" . }}-http:{{ .Values.service.http.port }}"I guess we could reuse the already configured
LOCAL_ROOT_URLfrom app.ini rendering above?fixed!
@@ -74,0 +76,4 @@value: {{ .Values.gitea.config.actions.GITEA__ACTIONS__ENABLED | quote }}- name: GITEA__SERVER__LOCAL_ROOT_URLvalue: {{ .Values.gitea.config.actions.GITEA__SERVER__LOCAL_ROOT_URL | quote }}{{- end }}This block shouldn't be necessary.
removed!
@@ -109,0 +116,4 @@- name: GITEA__ACTIONS__ENABLEDvalue: {{ .Values.gitea.config.actions.GITEA__ACTIONS__ENABLED | quote }}- name: GITEA__SERVER__LOCAL_ROOT_URLvalue: {{ .Values.gitea.config.actions.GITEA__SERVER__LOCAL_ROOT_URL | quote }}This block shouldn't be necessary.
removed!
@@ -246,0 +259,4 @@- name: GITEA__ACTIONS__ENABLEDvalue: {{ .Values.gitea.config.actions.GITEA__ACTIONS__ENABLED | quote }}- name: GITEA__SERVER__LOCAL_ROOT_URLvalue: {{ .Values.gitea.config.actions.GITEA__SERVER__LOCAL_ROOT_URL | quote }}This block shouldn't be necessary.
removed!
@@ -295,0 +315,4 @@value: {{ .Values.gitea.config.actions.GITEA__ACTIONS__ENABLED | quote }}- name: GITEA__SERVER__LOCAL_ROOT_URLvalue: {{ .Values.gitea.config.actions.GITEA__SERVER__LOCAL_ROOT_URL | quote }}{{- end }}This block shouldn't be necessary.
removed!
@@ -0,0 +16,4 @@- containsDocument:kind: ConfigMapapiVersion: v1name: gitea-unittests-act-runner-configWe should also ensure the content of the ConfigMap is correct.
added unit tests!
@@ -338,0 +407,4 @@tolerations: []affinity: {}token:Do we really need the
actions.provisioning.tokenobject? Isn't the crafted image reference identical to what{{ include "gitea.image" . }}from_helpers.tplwould already provide?removed!
I am hoping to pick this back up this week! FYI.
rebased: Add Gitea Actions act runnerto WIP: rebased: Add Gitea Actions act runner6c920c3074tod30ac63d7b@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.
WIP: rebased: Add Gitea Actions act runnerto rebased: Add Gitea Actions act runnerREDACTED.... 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_URLnot explicitly specified in my values file, I got a blank GITEA_INSTANCE_URL which prevented the StatefulSet from starting up.Values.actions.provisioning.enabledistrue, so I wasn't able to test out automated provisioning.Values.actions.persistenceOverall 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_URLissue.The
volumeClaimTemplateinStatefulSetis 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
readOnlyand using a patched gitea configuration file. TheLOCAL_ROOT_URLsetting 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 gitea/act_runner#280 (comment).
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 gitea/helm-chart#666 (comment) 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=1as environment variable for thedindimage1 . 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
dindimage. 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