Create 2022.01 release

[mrsimonemms]

Summary

In order to improve the acceptance of Gitpod self-hosted by the community and enterprise users, a formalised and regular release cycle of the Gitpod Installer is critical. This will be the first release of the Installer binaries and will be the template for how the process will run in future.

Context

Currently, the process is to instruct the community to find a specific (and arbitrary) build in Werft and use the build ID from there.

Acceptance Criteria

A release of the Installer is made with binaries for all the supported architectures

In Scope

• Builds of the Go binary for the following os/architectures (see go tool dist list):
  • linux/amd64
  • linux/386
  • linux/arm
  • linux/arm64
  • darwin/amd64
  • darwin/arm64
  • windows/386
  • windows/amd64
• Creation of a 2022.01 release in GitHub releases
• Creation of a 2022.01 tag
• Update the Gitpod guides to use the 2022.01 release
• Tested and working with in-cluster and external dependencies in:
  • AWS
  • Azure
  • GCP

Out of Scope

• Automation of pipeline. This is about working out the desired process. Automation will come for February's 2022.02 release
• Use of Replicated
• Non-Linux machines:
  • darwin/amd64
  • darwin/arm64
  • windows/386
  • windows/amd64

Tasks

• [Installer]: improve distrubtion of gitpod-installer binaries #6766
• Create releases/2022.01 branch
• Create a 2022.01 tag
• Define acceptance tests #7789
• Build binaries and add to GitHub releases
• Update docs on Gitpod.io to deprecate Helm and prefer Installer #7880
• Test on and update AWS guide
• Test on and update Azure guide
• Test on and update GCP guide
• [Installer]: validate cluster should accept a namespace #7497
• Update the Installer readme to remove references to ./installer etc and replace with downloaded binary
• Add note to docs about what data is collected by the telemetry #7820

[mrsimonemms]

So, one of the plans we had was to build the Installer binary for both Mac and Windows. Seemingly, because runc is only supported on Linux, when I run GOOS=darwin GOARCH=amd64 go build, we get a lot of runc and containerd compilation errors. I get the same when I run natively on a Mac.

An excerpt

# github.com/opencontainers/runc/libcontainer/cgroups
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:79:14: undefined: unix.Openat2
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:79:45: undefined: unix.OpenHow
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:100:18: undefined: unix.RESOLVE_BENEATH
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:100:41: undefined: unix.RESOLVE_NO_MAGICLINKS
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:101:17: undefined: unix.CGROUP2_SUPER_MAGIC
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:103:20: undefined: unix.RESOLVE_NO_XDEV
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:103:43: undefined: unix.RESOLVE_NO_SYMLINKS
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/v1_utils.go:155:9: undefined: Mount
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/v1_utils.go:163:87: undefined: Mount
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/v1_utils.go:191:37: undefined: Mount
../../go/pkg/mod/github.com/opencontainers/[email protected]/libcontainer/cgroups/file.go:103:43: too many errors

What should our resolution be for this 2022.01 release? As I see it, the most straightforward option is to only support Linux for this release and offer the Docker script for Mac/Windows users.

Any other suggestions? @corneliusludmann @csweichel

[metcalfc]

I think there are some syntax sugar bits we can add to make the container route more friendly. For example, #6763 would allow folks to pipe the config in vs need to do mount directories across. So something like:

alias gitpod-installer="docker run -i ...."
gitpod-installer init > "${CONFIG_FILE}"
vim "${CONFIG_FILE}"
cat "${CONFIG_FILE}" | gitpod-installer render -c - |  kubectl apply -f -

The entrypoint is mostly responsible for this magic.

cat /etc/hosts | docker run -i ubuntu cat

I'm sure there are better examples but the redis entrypoint is fairly simple: https://github.com/docker-library/redis/blob/a04a6df0a45894e1a630db4e84e0c12c7bcf326a/6.2/docker-entrypoint.sh