Interesting idea -- typically within the official images we're opposed to "master" / "main" / "trunk" / "tip" builds because they typically have a lot of churn, have to build from source, and aren't typically recommended for use by the relevant projects, but in this case, I think tip is sufficiently recommended for testing use by the project and the compilation of Go is lightweight enough that this might actually make some sense.

(This will need to make sure it doesn't auto-update too aggressively, but we've used approaches in other places that pin to something like a weekly commit that could be employed here - I'm thinking the day after the review meetings to maximize the number of features we squeeze into each build, so maybe Thursday mornings?)

I guess that's the long way of saying I'm not opposed, but I'd like to gauge a bit more interest, so hopefully other interested users will see this issue and give you a 👍 reaction. 😄

Shameless plug: https://github.com/AlekSi/golang-tip

One result of #500 (comment) is that this is a little bit harder to implement (both because of the changes here but also the upstream impact of golang/go#54265 now making it progressively harder each release to keep up using only distro packages).

In the end, it probably just means the approach would be different (not just slotting into our current "build from source" code, but a wholly separate "build from source" codepath, likely a separate template because once 1.22 is released and 1.20 is EOL, we won't be building from source at all anymore).