feat: add connectionCommandOverride and preConnectionCommandOverride parameters to values

docs/actions-dev.md

@@ -1,31 +0,0 @@
-# Gitea Actions
-
-In order to use the Gitea Actions act-runner you must either:
-
-- enable persistence (used for automatic deployment to be able to store the token in a place accessible for the Job)
-- create a secret containing the act runner token and reference it as a `existingSecret`
-
-In order to use Gitea Actions, you must log on the server that's running Gitea and run the command:
-    `gitea actions generate-runner-token`
-
-This command will out a token that is needed by the act-runner to register with the Gitea backend.
-
-Because this is a manual operation, we automated this using a Kubernetes Job using the following containers:
-
-1) `actions-token-create`: it uses the current `gitea-rootless` image, mounts the persistent directory to `/data/` then it saves the output from `gitea actions generate-runner-token` to `/data/actions/token`
-2) `actions-token-upload`: it uses a `bitnami/kubectl` image, mounts the scripts directory (`/scripts`) and
-the persistent directory (`/data/`), and using the script from `/scripts/token.sh` stores the token in a Kubernetes secret
-
-After the token is stored in a Kubernetes secret we can create the statefulset that contains the following containers:
-
-1) `act-runner`: authenticates with Gitea using the token that was stored in the secret
-2) `dind`: DockerInDocker image that is used to run the actions
-
-If you are not using persistent volumes, you cannot use the Job to automatically generate the token.
-In this case, you can use either the Web UI to generate the token or run a shell into a Gitea pod and invoke
-the command `gitea actions generate-runner-token`. After generating the token, you must create a secret and use it via:
-
-```yaml
-existingSecret: "secret-name"
-existingSecretKey: "secret-key"
-```

docs/connectionCommandOverride.md

@@ -0,0 +1,45 @@
+# Using a custom connectionCommand
+
+By default, before the container starts it tries to reach the given giteaRootURL.  
+Normally this is done by the busybox image using the wget binary.  
+
+However, due to [Issue #162](https://gitea.com/gitea/helm-actions/issues/162) there has been a change made where we can customize that command.  
+
+Using the `values.yaml` file by default it calls `wget --spider --no-check-certificate <your giteaRootURL>` with a timeout of 10 seconds.  
+But with a custom init section like detailed below we can make our check compliant with whatever certificate you have.  
+
+Assuming:
+```yaml
+enabled: true
+giteaRootURL: https://gitea.com
+existingSecret: foo
+existingSecretKey: bar
+
+init:
+  image:
+    registry: ""
+    repository: alpine
+    # Overrides the image tag whose default is the chart appVersion.
+    tag: "3.24"
+    digest: ""
+    pullPolicy: IfNotPresent
+    fullOverride: ""
+    connectionCommandOverride: "apk add curl && curl -I"
+```
+
+This now creates the following template section:
+
+```yaml
+        - name: init-gitea
+          image: "alpine:latest"
+          command:
+            - sh
+            - -c
+            - |
+              echo 'Trying to reach Gitea on https://gitea.com'
+              until timeout 10 apk add curl && curl -I https://gitea.com; do
+                sleep 3
+                echo "Trying again in 3 seconds..."
+              done
+              echo "Gitea has been reached!"
+```

docs/share-dind-with-job-container.md

@@ -1,30 +0,0 @@
-# Share dind with job container
-
-You can weaken isolation and allow jobs to call docker commands.
-
-## Limitations
-
--
-
-## Example Values
-
-```yaml
-    config: |
-      log:
-        level: debug
-      cache:
-        enabled: false
-      container:
-        require_docker: true
-        docker_timeout: 300s
-
-## Specify an existing token secret
-##
-existingSecret: "runner-token2"
-existingSecretKey: "token"
-
-## Specify the root URL of the Gitea instance
-giteaRootURL: "http://192.168.1.2:3000"
-```
-
-Now you can run docker commands inside your jobs.