Initial helm chart

[mkilchhofer]

Deploy via helm chart

I use nebraska in my homelab to update my flatcar hosts esp. to reduce the traffic for downloading the new images.
For this I made a helm chart.

Are you interested in this? I found not that much information about deploying and hosting nebraska in production.

What also could be nice to provide:

• docs about deploying in Kubernetes (with example yamls)
• docs about deploying in Kubernetes with Kustomize
• GitHub Actions for hosting the chart as a static resource in gh-pages (done with Helm Chart Releaser GitHub Action)

How to use

1. clone the repo
2. Update dependencies

 helm dependency update ./charts/nebraska

3. then run the following helm command

   helm install my-nebraska ./charts/nebraska -n kube-system

4. (customize if needed)

   helm upgrade my-nebraska ./charts/nebraska --set ingress.hosts={my-nebraska.example.com}

Testing done

• Added the Helm Chart Testing GitHub Action to trigger testing on every new PR

[joaquimrocha]

@johananl , Do you wanna take a look at this one?

[knrt10]

@mkilchhofer thank you for opening the PR. Really great work. Some NITs, can you please address them?

[mkilchhofer]

Hi @knrt10,
Do you plan to use the branch gh-pages and GitHub Pages? If not, I can also add a github action workflow which releases the chart through a GitHub release and updating an index.yaml file inside the branch gh-pages.

[joaquimrocha]

Hi @mkilchhofer , we have our own documentation system, so we don't plan on using gh-pages (unless I misunderstood your point).
A Github action to update stuff on release sounds fine. I intend to do that for the container image as well in the future.

[joaquimrocha]

the docs, BTW: https://kinvolk.io/docs/nebraska/latest

[mkilchhofer]

Hi @mkilchhofer , we have our own documentation system, so we don't plan on using gh-pages (unless I misunderstood your point).
A Github action to update stuff on release sounds fine. I intend to do that for the container image as well in the future.

Okay, perfect 👌
We need an empty gh-pages branch for this, which I cannot provision inside this PR:

$ # Prepare an empty branch
$ git checkout --orphan gh-pages
$ git reset
$ rm -r *

$ # Generate the index structure
$ cat <<EOF > index.yaml
apiVersion: v1
entries: {}
generated: "2021-03-01T00:00:00Z"
EOF

$ # Add the file
$ git add index.yaml
$ git commit -m 'Add empty index.yaml'
$ git push

[joaquimrocha]

Thanks again for another big push @mkilchhofer !
I was going to take a look now too but I'd like to ask you to squash the commits that you think should go together.
Ideally we should have atomic commits. Depending on this case, it may mean that all your commits should be squashed, or maybe there are a few that should be added separately.
However, we usually never squash commits together (unless their small fixups to one base commit) when merging PRs. So I kindly ask you to squash the commits to create the atomic ones you see as adequate, and that'll make the PR easier for another review round and testing.

[mkilchhofer]

Done :)
Please remember to bootstrap the new branch before merging.

Oh and please have a look at the releases page of the source branch repo: https://github.com/mkilchhofer/nebraska/releases
and also the repo tags: https://github.com/mkilchhofer/nebraska/tags.
The releaser action by default creates a GitHub Release for helm chart updates with this name convention: {{ .Name }}-{{ .Version }} (.Name = chart name, .Version = version of the Chart). This results in releases with the name "nebraska-x.y.z". Maybe we want to prefix the chart releases or simply replace the chart name with "helm" or something like that (as there is only one chart in this repo)? If so, we can configure the releaser like this: cr.yaml (juicefs-csi-driver)

To not confuse people with application releases and helm releases, I set the Release Name Template to {{ .Name }}-helm-{{ .Version }}. I hope, this is ok for you?

[knrt10]

Looks great @mkilchhofer. Some last Nits. Also I tested it, it works fine. Made some changes to description for user as a first time install. Hope that's okay.

[knrt10]

Thanks for the awesome work @mkilchhofer. LGTM. Tested it again with the new changes. Works fine.

[joaquimrocha]

Hi @knrt10,
Do you plan to use the branch gh-pages and GitHub Pages? If not, I can also add a github action workflow which releases the chart through a GitHub release and updating an index.yaml file inside the branch gh-pages.

Hi @mkilchhofer , I merged the PR but didn't realize it was still trying to use the gh-pages branch (which we don't use).
Can we use an alternative for this? Maybe using the Github Releases as you hinted in the message above, or does that still require the gh-pages branch?

Thanks.

[mkilchhofer]

Hi @knrt10,
Do you plan to use the branch gh-pages and GitHub Pages? If not, I can also add a github action workflow which releases the chart through a GitHub release and updating an index.yaml file inside the branch gh-pages.

Hi @mkilchhofer , I merged the PR but didn't realize it was still trying to use the gh-pages branch (which we don't use).
Can we use an alternative for this? Maybe using the Github Releases as you hinted in the message above, or does that still require the gh-pages branch?

Thanks.

Hi @joaquimrocha, Maybe I didn't understand your statement correctly. What I understand was that you do not use the branch gh-pages so it is available for this intent :-)

[joaquimrocha]

No :)
I meant I'd prefer to keep not using that branch, but I am guessing there's no greater alternative if we don't intend to host it somewhere else?

[mkilchhofer]

Exactly. We need to serve an index.yaml via https to the helm users. A next step could be to list this chart on https://artifacthub.io/ (only an index pointing to an external repository) then we would need an additional file for this besides the index.yaml