justusbunsi 8c4e8e8f30 Introduce bash scripting unittests (#724 )

### Description of the change

This adds an environment for unit testing our bash scripts, using [BATS](https://github.com/bats-core/bats-core).
It implements first tests for `config_environment.sh`.

### Benefits

Writing unit tests for bash scripts documents the expected behavior and allows it being a quality gate in our CI.

### Possible drawbacks

Not everyone is familiar with this approach and unit testing framework. Me neither, it took me some hours to get into it.

### Applicable issues

- Related to #691 where an issue in `config_environment.sh` was detected. It doesn't fixes it yet. This will be a dedicated Pull Request.

### Additional information

I've verified that the changes for Renovate are indeed working.

You may wonder why there is only one `run $PROJECT_ROOT/scripts/init-containers/config/config_environment.sh` and many `run execute_test_script` calls.
Usually, testing a script itself would be executing `run $PROJECT_ROOT/scripts/init-containers/config/config_environment.sh`. You then can assert the exit code and other things. Since the `config_environment.sh` exports environment variables and we are not able to access them from outside a `run` execution, the function `execute_test_script` wraps our script execution between environment comparison. Doing so allows us capture environment variables that were added/removed during script execution.

Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/724
Reviewed-by: pat-s <pat-s@noreply.gitea.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>

2024-12-20 09:45:01 +00:00

2.8 KiB

Raw Blame History

Contribution Guidelines

Any type of contribution is welcome; from new features, bug fixes, tests, refactorings for easier maintainability or documentation improvements.

Development environment

node at least current LTS
helm
make is optional; you may call the commands directly

When using Visual Studio Code as IDE, a ready-to-use profile is available.

Documentation Requirements

The README.md must include all configuration options. The parameters section is generated by extracting the parameter annotations from the values.yaml file, by using this tool.

If changes were made on configuration options, run make readme to update the README file.

The ToC is created via the VSCode Markdown All in One extension which can/must also be used used to update it.

Pull Request Requirements

When submitting or updating a PR:

make sure it passes CI builds.
do not make independent changes in one PR.
try to avoid rebases. They make code reviews for large PRs and comments much harder.
if applicable, use the PR template for a well-defined PR description.
clearly mark breaking changes.

Local development & testing

For local development and testing of pull requests, the following workflow can be used:

Install minikube and helm.
Start a minikube cluster via minikube start.
From the gitea/helm-chart directory execute the following command. This will install the dependencies listed in Chart.yml and deploy the current state of the helm chart found locally. If you want to test a branch, make sure to switch to the respective branch first. helm install --dependency-update gitea . -f values.yaml.
Gitea is now deployed in minikube. To access it, it's port needs to be forwarded first from minikube to localhost first via kubectl --namespace default port-forward svc/gitea-http 3000:3000. Now Gitea is accessible at http://localhost:3000.

Unit tests

Helm templating tests

# install the unittest plugin
$ helm plugin install https://github.com/helm-unittest/helm-unittest

# run the Helm unittests
make unittests-helm

See plugin documentation for usage instructions.

Bash script tests

# setup the environment
git submodule update --init --recursive

# run the bash tests
make unittests-bash

See bats documentation for usage instructions.

Release process

Create a tag following the tagging schema
Push the tag
Let CI do it's work

2.8 KiB Raw Blame History