.werft/build: Refactor installer steps into dedicated class

[ArthurSens]

Description

This PR tries to reduce amount of code under .werft/jobs/build/deploy-to-preview-environments.ts by moving all code related to installer to a dedicated Installer interface.

That way, we can make the deploy phase as simple as:

werft.phase(deploy)
const installer = newInstaller(params...)
try {
        installer.init(installerSlices.INSTALLER_INIT)
        installer.addPreviewConfiguration(installerSlices.PREVIEW_CONFIG)
        installer.validateConfiguration(installerSlices.VALIDATE_CONFIG)
        installer.render(installerSlices.INSTALLER_RENDER)
        installer.postProcessing(installerSlices.INSTALLER_POST_PROCESSING)
        installer.install(installerSlices.APPLY_INSTALL_MANIFESTS)
    } catch (err) {
        if (!jobConfig.mainBuild) {
            werft.fail(phases.DEPLOY, err)
        }
        exec('exit 0')
    }
werft.done(deploy)

I'm opening it as a draft just to collect early feedback on the approach. @gitpod-io/platform do you agree with the approach here?

How to test

• Start a preview on core-dev and make sure workspaces start
• Start a preview on Harvester and make sure workspaces start

Release Notes

NONE

[ArthurSens]

/werft run with-vm=true

[ArthurSens]

Tested on both core-dev and Harvester, so turning it into ready for review 🙂

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mads-hartmann]

Awesome Arthur. I think this could be improved further, I have left some comments in the review. I'm happy to talk through this more if that's helpful ☺️

[ArthurSens]

Thanks for all the Typescript tips Mads, the CI is still re-running but I believe I was able to do the refactoring using class and private methods 🙂

Learned a lot!

[mads-hartmann]

I left a few comments that you can follow up on in a later PR ☺️ I added the hold label in case you needed to do some last testing before merging

[mads-hartmann]

nit: We don't (as far as I know) have a convention to use upper or lower case for constants like these, but it would be nice to be consistent within the file. So either make these uppercase of make the uppercase ones lowercase ☺️

[mads-hartmann]

When you have a method/function that takes a lot of arguments I usually prefer to use an "options" argument instead (just as you have previously done here.) I has a few benefits

1. It becomes easier to read what the arguments are as they're named when you invoke the function. This is nice when you're reading code in a PR and not in your editor.
2. It's easier to add new arguments as you don't have to worry about the order.

So in this case it would look like this

export type InstallerOptions = {
  werft: Werft
  configPath: string
  // all the rest
}

export class Installer {
  // All your private members
  
  constructor(options: InstallerOptions) {
    this.werft = options.werft
    // all the rest
  }
}

And then when you invoke it

new Installer({
  werft: werft,
  configPath: configPath,
  /// and so on
})

[ArthurSens]

Ah nice, I really wasn't enjoying that method signature 😅

I'll change that real quick

[mads-hartmann]

Awesome, looks great 🛹