[kots]: configure werft build command

[mrsimonemms]

Description

Automate the KOTS process.

1. Runs make lint on the manifests during the build phase. Although this is far from perfect, it's a good indication if there are any problems in the manifests. As per the guidelines, warnings and below return successful. The replicated lint command requires the REPLICATED_APP and REPLICATED_API_TOKEN envvars being set. This is a bug in the system
2. Whenever a main build is successful, updates the gitpod-installer-job.yaml image tag and pushes to gitpod/unstable channel in Replicated.

Related Issue(s)

Fixes #8866

How to test

See release 20 as a demo of the replicated release create command working on any branch and then release 21 of it being wrapped in the if mainBranch conditional

And here's proof that the release to Replicated works

Release Notes

[kots]: configure werft build command

Documentation

[Pothulapati]

Awesome Work, @mrsimonemms! This should be really great for testing.

I don't have experience working with werft but I see that we did the following, to publish automatic unstable kots releases on main, and perform lint for builds

• Create a new build job in publish-kots-unstable that is toggled only if its a main job! As this performs the publishing.
• For the above job to work, we need the relevant env variables that we seem to have created K8s secrets for, and attach them as variables which are then passed to the job in build-and-publish.ts
• Update BUILD.yaml to include the lint action which we probably use for CI PR builds. (So, the required env variables are automatically passed here as they are on the same k8s cluster?)

/hold to get a @corneliusludmann review just to make sure that we aren't missing any of the werft stuff that I am not aware of!

[corneliusludmann]

Looks good to me as well. The comment I left is more a nit. Feel free to ignore or add a small follow-up PR. Nothing that should prevent us from merging this.

Probably a good idea if that person that removes the hold label has an eye on the main build to fix it in case we break it with this change.

By the way: I was wondering why the MIT license is used for these files. Maybe we need to figure out if this is really what we want. Most of our stuff is under AGPL and not MIT.

[corneliusludmann]

Wouldn't it be easier to just use process.env.REPLICATED_API_TOKEN and process.env.REPLICATED_APP instead?

[mrsimonemms]

Looks good to me as well. The comment I left is more a nit. Feel free to ignore or add a small follow-up PR. Nothing that should prevent us from merging this.

I'll do a follow-up PR. It hadn't occurred to me at the time.

By the way: I was wondering why the MIT license is used for these files. Maybe we need to figure out if this is really what we want. Most of our stuff is under AGPL and not MIT.

I just used the leeway command to generate the license statement. I'll have a look into this and do a follow-up PR if necessary

[mrsimonemms]

/unhold