You've already forked helm-gitea
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
🤖 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>
80 lines
3.1 KiB
Markdown
80 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
|