feat(installer): use cloudsmith instead of gh to fetch preview version

[slonka]

gh requires a valid token - in this PR I exchange it for cloudsmith which does not and now people who don't have a valid token can try out the preview version

Did you sign your commit? Instructions yes

Have you read Contributing guidelines? yes

[netlify[bot]]

✅ Deploy Preview for kuma ready!

Name	Link
🔨 Latest commit	fae27d2a49d13f27fe0c5e8400949e63371a51c5
🔍 Latest deploy log	https://app.netlify.com/sites/kuma/deploys/661cf0bbffae350008781d4c
😎 Deploy Preview	https://deploy-preview-1733--kuma.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 94 (🟢 up 3 from production) Accessibility: 90 (no change from production) Best Practices: 100 (no change from production) SEO: 85 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[slonka]

@lahabana WDYT about ☝️ , should we have two versions: "preview" and "last-build" or something similar? Also to have preview without successful e2e tests we need to change things around

[lahabana]

The end story is why do we have previews in this script?

My original idea when I added this was: being able for external users to use a trusted build to check upcoming features, validate fixes... For this having VERSION=preview be something we think works (e2e pass) would be useful. @michaelbeaumont definition of what this script should return seems different as: something for the dev team to debug which I think is different and orthogonal to this.

For @michaelbeaumont 's usecase you can always open a PR with e2e tests skipped to get something equivalent (or just build locally). I think using cloudsmith solves a bunch of access issues which I think is meaningful (external users able to use VERSION=preview is a use case). If we want to do this real difference I think what should happen is build, push to a prerelease area (this includes docker images) then once validated move to the actual release area. In that case you could use cloudsmith (and docker) for both and even have latest docker tags.

[michaelbeaumont]

@michaelbeaumont definition of what this script should return seems different as: something for the dev team to debug which I think is different and orthogonal to this.

No. my point is about allowing users to run KM independent of whether e2e tests complete. we had multiple cases where customers were trying to test out master builds but e2e flakes stopped this from happening.

PREVIEW=version was explicitly not for debugging. It should return a stable version of KM. For debugging you pass a version. The problem is that we no longer even build when e2e tests don't run for some reason. The objection I have here is that down the line someone will say we can't reintroduce this because it will break this script.