8f35f45e31
Following the creation of the changelog via `git-sv`, the release process can also be simplified. The new approach only requires to call `git sv tag` from a Maintainer with write access to the repo. This will create and push the tag. The release notes and subsequent Gitea release will then be created by the new workflow job. Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/865 Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
81 lines
3.1 KiB
Markdown
81 lines
3.1 KiB
Markdown
# Contribution Guidelines
|
|
|
|
Any type of contribution is welcome; from new features, bug fixes, tests,
|
|
refactorings for easier maintainability or documentation improvements.
|
|
|
|
## Development environment
|
|
|
|
- [`node`](https://nodejs.org/en/) at least current LTS
|
|
- [`helm`](https://helm.sh/docs/intro/install/)
|
|
- `make` is optional; you may call the commands directly
|
|
|
|
When using Visual Studio Code as IDE, a [ready-to-use profile](.vscode/) 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](https://github.com/bitnami-labs/readme-generator-for-helm).
|
|
|
|
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](https://marketplace.visualstudio.com/items?itemName=yzhang.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](https://www.conventionalcommits.org/en/v1.0.0/#specification) schema
|
|
|
|
## Local development & testing
|
|
|
|
For local development and testing of pull requests, the following workflow can
|
|
be used:
|
|
|
|
1. Install `minikube` and `helm`.
|
|
1. Start a `minikube` cluster via `minikube start`.
|
|
1. 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`.
|
|
1. 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](http://localhost:3000).
|
|
|
|
### Unit tests
|
|
|
|
#### Helm templating tests
|
|
|
|
```bash
|
|
# install the unittest plugin
|
|
$ helm plugin install https://github.com/helm-unittest/helm-unittest
|
|
|
|
# run the Helm unittests
|
|
make unittests-helm
|
|
```
|
|
|
|
See [plugin documentation](https://github.com/helm-unittest/helm-unittest/blob/main/DOCUMENT.md) for usage instructions.
|
|
|
|
#### Bash script tests
|
|
|
|
```bash
|
|
# setup the environment
|
|
git submodule update --init --recursive
|
|
|
|
# run the bash tests
|
|
make unittests-bash
|
|
```
|
|
|
|
See [bats documentation](https://bats-core.readthedocs.io/en/stable/) for usage instructions.
|
|
|
|
## Release process
|
|
|
|
1. Ensure you have [`git-sv`](https://github.com/thegeeklab/git-sv) installed
|
|
1. 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)
|
|
1. Let CI do it's work
|