Christopher Homberger 5b19636034

changelog / changelog (push) Successful in 21s

Details

check-and-test / check-and-test (push) Successful in 1m8s

Details

chore(core): refactor to make all unit tests pass (#6 )

_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>

2025-03-30 23:13:31 +00:00

1.7 KiB

Raw Blame History

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:

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
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:

act-runner: authenticates with Gitea using the token that was stored in the secret
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:

provisioning:
  enabled: false
existingSecret: "secret-name"
existingSecretKey: "secret-key"

1.7 KiB Raw Blame History

Gitea Actions

1.7 KiB

Raw Blame History