Files
helm-gitea/CONTRIBUTING.md
Markus Pesch 4d6db83c28
Some checks failed
Run Helm tests / Execute helm lint (push) Successful in 11s
Run Helm tests / Execute helm template (push) Failing after 11s
Run Helm tests / Execute helm unittest (push) Successful in 28s
Markdown linter / Execute npm run readme:link (push) Successful in 36s
Markdown linter / Execute npm run readme:lint (push) Successful in 8s
Markdown linter / Execute npm run readme:parameters (push) Successful in 27s
fix(ci): improve workflows (#959)
🤖 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>
2025-10-03 07:38:26 +00:00

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

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

  1. Install minikube and helm.
  2. Start a minikube cluster via minikube start.
  3. From the gitea/helm-gitea 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.
  4. 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

  1. Ensure you have git-sv installed
  2. 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)
  3. Let CI do it's work