mirror of
https://gitea.com/gitea/helm-actions.git
synced 2026-04-05 09:10:46 +00:00
<!-- Before you open the request please review the following guidelines and tips to help it be more easily integrated: - Describe the scope of your change - i.e. what the change does. - Describe any known limitations with your change. - Please run any tests or examples that can exercise your modified code. Thank you for contributing! We will try to review, test and integrate the change as soon as we can. --> ### Description of the change <!-- Describe the scope of your change - i.e. what the change does. --> ### Benefits <!-- What benefits will be realized by the code change? --> ### Possible drawbacks <!-- Describe any known limitations with your change --> ### Applicable issues <!-- Enter any applicable Issues here (You can reference an issue using #). Please remove this section if there is no referenced issue. --> - Fixes # ### Additional information <!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. --> ### ⚠ BREAKING <!-- If there's a breaking change, please shortly describe in which way users are affected and how they can mitigate it. If there are no breakings, please remove this section. --> ### Checklist <!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] --> - [ ] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm) - [ ] Breaking changes are documented in the `README.md` - [ ] Helm templating unittests are added (required when changing anything in `templates` folder) - [ ] Bash unittests are added (required when changing anything in `scripts` folder) - [ ] All added template resources MUST render a namespace in metadata Reviewed-on: https://gitea.com/gitea/helm-actions/pulls/116 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Daan Selen <dselen@nerthus.nl> Co-committed-by: Daan Selen <dselen@nerthus.nl>
32 lines
1.7 KiB
Markdown
32 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
|
|
existingSecret: "secret-name"
|
|
existingSecretKey: "secret-key"
|
|
```
|