🤖 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>
The following patch adds support for network policies.
The patch does not contain any specific network policies, as it is uncertain in which environment and with which access rights gitea will be deployed.
With regard to third-party components such as PostgreSQL or Valkey, the network policy may need to be adjusted. Whether this happens directly in the helm chart or whether the user has to enter it themselves is open to discussion.
During testing, I defined a few sample network policies to get Gitea up and running. These are only examples.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/952
Reviewed-by: DaanSelen <daanselen@noreply.gitea.com>
Co-authored-by: Markus Pesch <markus.pesch@cryptic.systems>
Co-committed-by: Markus Pesch <markus.pesch@cryptic.systems>
The following patch intoduce the dictionaries pre and postExtraInitContainers.
The dictionaries can be used to specify further initContainers before and after
the gitea initializing process. For example:
```yaml
postExtraInitContainers:
- name: foo
image: docker.io/library/busybox:latest
preExtraInitContainers:
- name: bar
image: docker.io/library/busybox:latest
```
#916
After many years of maintaining this chart alongside @justusbunsi, I am also stepping down as a maintainer.
In the following, I want to inform users about the reasons.
I am on an independent journey since ~ 1 year, which brought many new challenges and responsibilities.
Since then I have created many devops-related assets (charts, Ansible role, images) which I am now curating as part of my professional work.
Besides, I have also continued with all my FOSS-related efforts. This has summed up to ~ 20-30 projects for which I am either in a primary or secondary maintainer role.
While I have a lot of fun in this, I need to ensure to not go beyond my limits and focus on the ones which I also use in my daily dev & professional life.
Gitea isn't among these anymore since some time, which brings me to the second part of why I am stepping down:
After thinking about it for a long time and being torn between worlds, I've decided to go with Forgejo instead of Gitea for most instances I am running/maintaining.
Since then, I have used the Gitea helm chart to deploy these. This has worked out great and without issues and will likely continue to do so for the foreseeable future.
However, it lately started to feel "wrong", i.e. to continue using the Gitea chart for Forgejo deployments, especially after both projects have substantially diverged some time ago already and a Forgejo Helm Chart exists since some time. Also, I had the feeling of not being able to "commit" to one of the projects fully, being involved in both.
After launching [CodeFloe](https://codefloe.com) a few weeks ago, a public Forgejo instance, I came to the conclusion to step down as a maintainer and focus on the software that I use daily.
And as I like be fully transparent: I don't wanna hold back on the fact that I was also missing the community spirit from "the old days" quite a bit lately, both in the Discord server and the discussions in the chart. The ratio of low-quality requests in the Chart increased a lot over the last ~ 1.5 years, while at the same time the average response times of Gitea core member increased to weeks.
I hope the Gitea community can turn this around again and create a welcoming place to which its fun to contribute to in one's spare time. I enjoyed it for the most part and want to thank everyone who supported me during this time, for the general trust in Chart-related decisions, and the opportunity to personally improve on Helm chart management in general.
Reviewed-on: https://gitea.com/gitea/helm-gitea/pulls/918
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
