x/build/cmd/relui: create production and staging environments

[toothrot]

• Staging
• Production
• TBD?

Blocked by #47401

[gopherbot]

Change https://golang.org/cl/369254 mentions this issue: cmd/relui: add cloud build configuration

[dmitshur]

TBD?

Edit: I originally suggested a "dry-run" semi-environment, but by now think that needs to be a separate mode. It probably deserves its own issue as this issue is about setting up actual running environments, so I'll withdraw the comment for now.

Original comment

In addition to production and staging, I suggest having a third semi-environment, "dry-run mode". It would be intended for local execution and wouldn't need to be deployed anywhere. It would be similar to how releasebot behaves with -dry-run flag: run as much of the same code as possible but skip all external effects.

We can change the color scheme of the header for all 3 modes so they're easy to tell apart, e.g., something like:

---

---

[dmitshur]

@toothrot Should the "Production" checkbox be checked now, given #47401 is resolved and we have https://build.golang.org/releases/?

I'm about ready to send CLs that'll resolve #47402. That means running cmd/relui locally would allow production workflows to be run (and no other option, unless code is modified locally), unless we make progress on this issue to allow selecting a non-production environment or mode.

I don't know what we want the long-term solution for this to be, perhaps that needs more discussion. As an intermediate step here to enable progress, are you okay with reusing the existing x/build/buildenv package and its idioms for cmd/relui, or would you prefer a different path instead?

(If it is a goal not to use x/build/buildenv in cmd/relui, we can instead add an explicit flag that controls where the Twitter API credentials are fetched from, and control its prod value in deployment-prod.yaml.)

[dmitshur]

I don't know what we want the long-term solution for this to be, perhaps that needs more discussion.

I've had a chance to cover this with @heschi today, and I think we found agreement on something with good properties that might not take too much time to begin with. In that case, the intermediate step of reusing buildenv won't be worthwhile. I opened #51122 as the tracking issue for it.

[gopherbot]

Change https://go.dev/cl/410235 mentions this issue: cmd/relui: upgrade to Go 1.18 and Debian 11