Re-design chart & publishing flow

[crandles]

Review the currently supported helm charts and the overall release process for the project.

• Review current publishing process
• Review current chart
• Identify options for simplification

[crandles]

The current chart release process:

• any change pushed to a branch named trickster-* is published via workflow using the helm-chart-releaser
• the helm-chart-releaser packages the charts in the given trickster-* branch and publishes them to the gh-pages branch
• Trickster users interact with the https://helm.tricksterproxy.io/ endpoint, which routes to the gh-pages branch of the repository (via Github Pages)

[crandles]

On chart publishing tooling:

1. Publish helm charts to an OCI backend

• Option 1: Docker Hub
• Option 2: Github (ghcr.io)

2. Continue publishing using helm-releaser

• Requires the continued maintenance/ownership of helm.tricksterproxy.io DNS

I think it would simplify things from a maintenance perspective to push charts via OCI, to the same backend we push images to.

[crandles]

On the release workflow design:

• The current model relies on maintaining a branch per minor version of trickster
  • This tightly couples the application versioning with the deployment process (while allowing us to maintain long-term support)
• After updating a release branch, a workflow is executed on commit to publish the chart to gh-pages

Current proposal:

• We should keep the current branches/workflow around (for a time period past the v2 release), as they may still be utilized
• Going forward, we should decouple the helm chart version from the trickster application version
  • This will mean the chart version should not be impacted by minor trickster version changes
  • The chart may be impacted my major trickster release versions
    • this is unavoidable if we break the flags or e.g. port assumptions, but in practice we will hopefully not encounter this
• If there is a breaking change to the chart (or trickster, which requires a breaking change to the chart), we should create a new chart and maintain both charts out of the main branch.

[crandles]

On testing:

• we should scan the chart with checkov + additional security tooling
• consider a simple trickster deployment test (trickster running in a kind cluster + mostly empty config)
• defer any complex, coordinated e2e testing for another effort
  • If we follow the goal of decoupling the chart from trickster application logic, we should be able to limit the scope of testing chart changes