Draft: Helm chart improvements & publication to public repo

[ianroberts]

This PR includes a few miscellaneous improvements to the Helm chart

• Update postgresql subchart, and don't force the use of an existingSecret (this was a holdover from earlier in my development of the chart when i was using an older Helm that couldn't extract the generated secret name from the postgresql subchart)
• Use published ghcr.io images by default
• Add documentation to the developer guide

but the most important change is that I've set up a chart repository on repo.gate.ac.uk so we will be able to follow normal Helm practice and publish versioned copies of the chart in a way that allows them to be installed without having to clone the whole gate-teamware repo. A cluster manager will be able to do

helm repo add gate https://repo.gate.ac.uk/repository/charts
helm repo update

create their own values.yaml with config overrides, then

helm upgrade --install gate-teamware gate/gate-teamware \
       --namespace teamware-prod --values prod-values.yaml

to get the latest stable version of Teamware without having to clone anything.

The bit I'm still puzzling over is exactly what the release cycle is going to look like. Helm charts are typically versioned independently of the version numbers of the software that they are installing (e.g. the postgresql subchart we depend on is versioned 11.x but installs postgresql 14) and there's a distinction in the Chart.yaml between the app version and the chart version. The chart version changes on every change to the chart, even if that's just to upgrade one of the dependencies.

The way I've got the chart set up at the moment it uses the appVersion from Chart.yaml as the default docker image tag for ghcr.io/gatenlp/teamware-backend and teamware-static. Those immutable-tagged images are built by a GitHub workflow that fires when we create a vX.Y tag on GitHub. If the chart was in lock-step with the app version then we could have a nice workflow where the vX.Y tag triggers a build of the docker images and also publishes the chart to the repository, which should nicely mean that we only publish an appVersion: X.Y chart once we've also published X.Y-tagged images. But if it's only the tag workflow that publishes charts then we can't update the chart without bumping the appVersion.

If instead we publish the chart on every push to dev, that means we can update the chart for a given appVersion as often as we want, but since we don't want to publish a chart with a given appVersion until the matching docker images exist, it means that if you look at the state of the repository at the point of a given vX.Y tag, the chart in that revision will still be one that installs version X.(Y-1). When we put a chart for a new appVersion onto dev, that published chart will be broken until the release cycle is complete, dev has merged to master and the vX.Y tag exists.

I can't see a "nice" way out of this other than to move the chart to its own repository separate from the rest of Teamware... can you see any way to square this circle?

[github-actions]

Jest Coverage

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	78.2	76.63	71.66	78.2

Details

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	78.2	76.63	71.66	78.2
_src/components	77.14	77.35	85.71	77.14
_ AnnotationRenderer.vue	76.23	77.35	84	76.23	126,141-142,196,219,240,247-261,269,275-285,319
_ MarkdownEditor.vue	100	100	100	100
_ MarkdownRenderer.vue	100	100	100	100
_src/components/annotation	78.57	86.66	76.47	78.57
_ CheckboxInput.vue	85.71	100	100	85.71	19
_ HtmlDisplay.vue	80	100	100	80	26-30
_ InputErrorDisplay.vue	100	0	100	100	19-25
_ RadioInput.vue	71.42	100	66.66	71.42	19,26
_ SelectorInput.vue	71.42	100	66.66	71.42	20,27
_ TextInput.vue	75	100	66.66	75	26
_ TextareaInput.vue	66.66	100	50	66.66	20
_src/enum	100	100	100	100
_ DocumentTypes.js	100	100	100	100
_src/jrpc	90.32	83.33	75	90.32
_ index.js	90.32	83.33	75	90.32	29,38-39
_src/utils	70.58	69.69	27.27	70.58
_ annotations.js	100	100	100	100
_ dict.js	100	100	100	100
_ index.js	55.88	54.54	11.11	55.88	9-14,28-93
_tests/unit	100	100	100	100
_ globalVue.js	100	100	100	100

[ianroberts]

The more I think about this the more I’m coming round to the idea of a separate GateNLP/charts repo for all our public Helm charts (initially only this one but could add others later). This is in line with how Bitnami works with a separate repo for each of the actual images and then one “charts” repo that holds all the independently versioned charts for everything.

[ianroberts]

Following discussion with @davidwilby I will close this PR and start a new one with just the documentation changes, once I've migrated the chart itself to a separate repo.