5b19636034
_This is the first time I ever messed with helm and is an experiment to show what prevents the tests to pass and how far it still depends on the gitea chart_ ### Description of the change - Deletes a single test that seems to depend directly on gitea - make all tests pass - Moves all value accesses from `actions` one level up - Copies content of the gitea chart required by the existing test - Reveals all dependencies that needs to be decoupled - Fixes readme generation - add package.json - copy dependent readme section from helm-gitea - Removes all dependencies - giteaRootURL is now required to be provided - consistency check that this value has been provided - added test for consistency failure - nc command no longer uses an hardcoded dns name and is checked in tests - added test - Copied yamllint from helm-gitea - added pnpm lock file exclusion - Installed pnpm in the workflow - Updated make unittest command in CI to unittest-helm ### Benefits The existing tests are passing ### Possible drawbacks The provision job might still not work. ### Applicable issues - Fixes #5 ### Additional information The following usage should now deploy ```yaml existingSecret: "somesecret" existingSecretKey: "key" ## Specify the root URL of the Gitea instance giteaRootURL: "http://somedomain:3000" ``` ### ⚠ BREAKING - giteaRootURL is now required to be provided - Moves all value accesses from `actions` one level up - The values.yml had this change without updating tests / dev Readme Reviewed-on: https://gitea.com/gitea/helm-actions/pulls/6 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.com> Reviewed-by: volker.raschek <markus.pesch@web.de> Co-authored-by: Christopher Homberger <christopher.homberger@web.de> Co-committed-by: Christopher Homberger <christopher.homberger@web.de>
34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# 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
|
|
provisioning:
|
|
enabled: false
|
|
existingSecret: "secret-name"
|
|
existingSecretKey: "secret-key"
|
|
```
|