deploy gp cli independent

[akosyakov]

In prod we still build images with mk2, which ships gp as part of the Gitpod layer. In preparation for mk3 we started to ship gp with supervisor:

gitpod/components/supervisor/pkg/supervisor/supervisor.go

Lines 390 to 399 in d3ce797

	for k, v := range binaries {
	var (
	from = filepath.Join(base, k)
	to = filepath.Join("/usr/bin", v)
	)
	err = os.Symlink(from, to)
	if err != nil && !os.IsExist(err) {
	log.WithError(err).WithField("from", from).WithField("to", to).Warn("cannot create symlink")
	}
	}

If the gitpod-layer is present, /usr/bin/gp will be present which makes the symlink operation fail.

To ship the gitpod-cli independently of the gitpod-layer even with mk2, we could just delete the to path prior to symlinking, i.e.

	 for k, v := range binaries {
		var (
			from = filepath.Join(base, k)
			to   = filepath.Join("/usr/bin", v)
		)

		// New code
		_ = os.Remove(to)
		// ends here

		err = os.Symlink(from, to)
		if err != nil && !os.IsExist(err) {
			log.WithError(err).WithField("from", from).WithField("to", to).Warn("cannot create symlink")
		}
	}

Error checking is left as an exercise to the reader. Beware that os.IsNotExist(err) is a valid case if there's no gitpod-layer.

[loujaybee]

🤔 This is an interesting one, what would the deploy path/process look like by the end of the changes? Where would the prod artifact be stored/fetched from?

[csweichel]

It would mean that gitpod-cli changes are subject to the same lifecycle as supervisor changes. Once
#6512 is built and merged you could ship gitpod-cli versions as part of the supervisor release yourself. Before that the updates would ship with workspace cluster deployments, much like supervisor changes do today.

[corneliusludmann]

/assign