Basic Helm Chart Support

[stevefan1999-personal]

Implemented items per the requirements on #12178

Missing items:

1. Testing infrastructure. This is gonna be super hard because we need to pop a Kubernetes cluster out of nowhere. A good starting point would be the Oracle Cloud with their free ARM nodes (given NodeBB supposedly can run on ARM64). I suggest manually testing it until we can sort this out in the long term.
2. Publication to Github Pages. This means we need the NodeBB organization to specifically enable the Github Pages for this purpose which may or may not worth the trouble(s)
3. In addition to #.1 and #.2, it is also best to update the Github Actions to cater this new chart. But this would be more of a long term vision.
4. Making sure dependabot will automatically update the subcharts. I assume it will work out of the box but I can't be certain for anything. Making this an unknown/missing item first.

Interesting stuff:

1. https://github.com/helm/kind-action. Maybe we can run an example Kubernetes cluster inside a Github Actions environment...? With 2 cores, 7 GB of RAM and 14 GB of storage I think it is going to be a big kill. Not really want to do that though. With a self-hosted runner maybe...
2. https://github.com/helm/chart-releaser-action is good for...releasing charts to Pages using Actions of course.
3. There is also https://github.com/helm/chart-testing-action...for testing and linting the charts itself, but it does not do integration tests (far as I know)
4. Not sure if we can integrate vcluster with kind-action so that we can have a clean and absolutely reproducible k8s environment to test things. I personally want to use this as an experiment and seeking for generalization to other places as well.

[nodebb-misty]

💡 Friendly Note

This pull request was made against the develop branch, which is reserved for commits destined for a minor or major release.If your commits simply fixes a bug, please rebase this PR against the master instead.

• patch releases — bug fixes only
• minor releases — new features, enhancements, and bug fixes
• major releases — breaking changes, including all of the above

Thanks!

[stevefan1999-personal]

Basic manual integration tests with MongoDB works very well with both replicaset and standalone mode! Will try other databases and manual case too!

[stevefan1999-personal]

and with postgres also tested and working as expected...I think the charts are ready, maybe we can improve the testing infra later on.

[stevefan1999-personal]

Also manually tested on my own Oracle Cloud K8S cluster with ARM64. As expected, it worked like a charm. The only problem is that managed mongo won't work on ARM64, since it was blocked by bitnami/containers#40947 (comment). You may have to go far out to use the official MongoDB K8S operator in order to get it to work.

[stevefan1999-personal]

@oplik0 @barisusakli Maybe we should move this out of the NodeBB main repo, can you guys make a NodeBB/charts repo instead?

[oplik0]

Seems like a good idea for expanding on CI and testing - while the releaser itself isn't an issue (since it seems to run pretty quickly) I imagine the additional testing might add a few minutes to Actions runtime.

It does make automatically running CI a bit more complicated - probably the docker workflow will need to call workflow dispatch via GH API - but it shouldn't be that bad.

I can't make the repo though since I'm just a contributor and don't have any special access to NodeBB org :)

Also, on Dependabot, NodeBB is using Renovate instead and it supports Helm out of the box. Dependabot is developing very slowly (outside of the notification spam part) so I'm really not sure if they support Helm yet.

[stevefan1999-personal]

@oplik0 Should we further cache the Verdaccio packages in GHA or is it just fine? Right now, the basic integration test takes about 10 minutes (20 minutes using act, a GHA simulator, I'm not sure why), and the time to run it can be a detrimental cost to the testing pipeline, so it is better to split it off to another repo and do the tests on demand.

[oplik0]

In a separate repo I think it'll be fine. Thankfully GitHub doesn't charge for CI in public repos (since, considering their LFS billing model, it probably wouldn't be usable :) and it shouldn't stall the entire NodeBB pipeline in that case.

[stevefan1999-personal]

In a separate repo I think it'll be fine. Thankfully GitHub doesn't charge for CI in public repos (since, considering their LFS billing model, it probably wouldn't be usable :) and it shouldn't stall the entire NodeBB pipeline in that case.

@julianlam Maybe you would be the right person to make that repo tho?