charts VS renovate

Spinning up workloads in kubernetes is much different than just spinning up a container in docker or even with docker compose. If someone has not already packaged it in a helm chart or some other kubernetes workload you'll have to develop one yourself. There are some nice library charts you can use as a base that should handle just about any random docker image you want to deploy. https://github.com/bjw-s/helm-charts/tree/main/charts/library/common there is also a repo of pre developed charts for common images. https://github.com/k8s-at-home/charts but be aware it was recently deprecated so it won't be receiving any updates.

Take a look at https://github.com/k8s-at-home/charts (recently deprecated but still a fantastic resource) - there are charts for the popular Arrs , tools, etc. You could deploy each chart individually into a namespace, or you could create yourself an "umbrella" chart which pulls in all the necessary charts as dependencies.

Library charts. A very thorough example can be seen here and usages of it here.

Could it be related to this? https://github.com/k8s-at-home/charts/pull/1435/files

I'd submitted a helm chart at https://github.com/k8s-at-home/charts/tree/master/charts/stable/firefly-iii if you want to try out

I know /u/stefantigro means well but the way you are both doing the helm charts is not ideal, helm charts are meant to be shared, not as a means to install apps into your cluster from a local folder. While they can be, it's not a good pattern. Take the helm chart from here for example. This is a published helm chart you can install using the commands in the Readme and you only need to provide the configuration for your instance from the values.yaml file. You can take a look at the values I use for this helm chart here. You can also see I'm using an custom Sonarr image, this image is tailored to running in Kubernetes

There is a working Helm chart for k8s-at-home that should be a good starting point. The biggest hurdle I see is that homebridge can conflict with SCALE's mDNS service as seen in this linked post.

There's an actual helm chart published here.

To automate library version updates, I introduced Renovate. Although I'm not very familiar with it, adding the following JSON file to the repository enables it to work:

Read more about Renovate and its documentation.

Synk, an excellent tool that identifies vulnerabilities in Spring Cloud dependencies. It can also be integrated with GitHub, GitLab, and Bitbucket. A reliable tool to monitor your repositories. You can also check out Renovate, another open-source tool that can automate dependency updates. In addition, our other recommended tool is Dependabot, now part of GitHub, which checks for outdated dependencies.

Renovate Bot- Free Community Plan

I tried it on https://github.com/renovatebot/renovate

It deleted 100s of files, most of which were Jest test files, and potentially all of which were a mistake. I restored them all with `git restore $(git ls-files -d)`.

I then ran `tsc` on the remaining _modified_ files and `Found 3920 errors in 511 files.`

Obviously at that point I had no choice but to discard all changes and unfortunately I would not recommend this for others to even try.

Once Renovate is integrated to track your GitOps repo, it will look for Glasskube packages and compare their versions to the official package repositories. When new versions are available, it will automatically open a PR. Once merged, you’ll be running the latest versions of your packages.

Thanks for your input, let me comment on your points one by one.

> However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo.

Glasskube packages can also be put inside a GitOps repository as every package is a CR (custom resource). (They can even be configured via the CLI using the `--dry-run` and `--output yaml` flags and than put into git. In addition we are working on pull request to support package updates via Renovate: https://github.com/renovatebot/renovate/issues/29322

> The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that.

As helm3 is now a client side tool only, that means that it can't enforce any RBAC by itself. OLM introduced Operator Groups (https://olm.operatorframework.io/docs/advanced-tasks/operato...) which introduces a permissions on an operator level. We might introduce something similar for Glasskube packages. Glasskube itself will still require be quite powerful, but we can than scope packages and introduce granular permissions.

To get started with Mend Renovate, the comprehensive official documentation provides detailed instructions on installation, configuration, and best practices. Additionally, the Mend Renovate community forum offers a platform for users to connect, share experiences, and access the collective knowledge base.