🤖 Split up helm chart workflows The following patch adapts the CI workflows. The worflows has been splitted into dedicated parts. For example the `helm template` and `helm unittest` command is now a seperate step to notice that a change affects the template mechanism but not the unittest. This was priviously not possible, because both commands were part of one step. 🤖 Changelog Issue Additionally has the changelog workflow be improved. The shell commands has been migrated to a dedicated file named `.gitea/scripts/changelog.sh`. This has the advantage, that the shellcheck plugin of IDE's support developers by developing such shell scripts. Furthermore, the used container image has been replaced by the ubuntu:latest image of the act_runner. This make it more comfortable in using `curl` or `jq`, because the complete set of features/flags are avialable instead of the previously used container image `docker.io/thegeeklab/git-sv:2.0.5`. Final note to the shell script `changelog.sh`, this can now be executed locally as well as on ARM-based act_runners and helps to test the helm chart in own Gitea environments beforehand. 🤖 Markdown linter In addition, a new workflow for markdown files has now been introduced. This checks the `README.md` file for links, ensures that it is properly formatted, and verifies that the parameters match those in `values.yaml`. Here, too, the commands have been outsourced to separate jobs so that more precise interaction is possible in the event of an error. ⚠️ Warning This patch also requires an adjustment in branch protection. There, the workflows that must be successful before a merge must be redefined. Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/959 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems> Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems>
3.1 KiB
Contribution Guidelines
Any type of contribution is welcome; from new features, bug fixes, tests, refactorings for easier maintainability or documentation improvements.
Development environment
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.
- format the PR title following the conventional commits schema
Local development & testing
For local development and testing of pull requests, the following workflow can be used:
- Install
minikube
andhelm
. - Start a
minikube
cluster viaminikube start
. - From the
gitea/helm-gitea
directory execute the following command. This will install the dependencies listed inChart.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 fromminikube
to localhost first viakubectl --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
- Ensure you have
git-sv
installed - Run
git sv tag
(this creates and pushes the tag following the respective next tag according to the semver commits issued since the last release) - Let CI do it's work