x/website: tracking bug for tip.golang.org #30232
Comments
|
Looks like x/website still has the autocert code. This bug might just be validating that the tip service still runs (it'll need slight tweaks) on the go-dashboard-dev staging project's GKE cluster. |
|
As part of the changes of moving website into x/website, we have to make a decision about the future scope of tip.golang.org. Previously, tip.golang.org served two purposes: it served the latest content from the main Go repository (e.g., https://tip.golang.org/doc/go1.12, the latest spec.html, latest stdlib package docs), and it was a test of whether Go at tip builds at all. If there was a toolchain breakage (e.g., early in cycle), the latest tip commit couldn't be deployed. This is because to serve the website, the Go distribution had to be built together with the x/tools/cmd/godoc binary. Now that the website is served from x/website/cmd/golangorg, it becomes possible to use a fixed stable version of Go (rather than the tip commit) to serve the latest content from the Go repository. That would make tip.golang.org more reliable and change its purpose to only serve the latest Go repo content, not to see if the latest tip commit builds successfully (we have https://build.golang.org/ for that). (I left a comment about it in code review here.) Thoughts on this? |
|
It was never a goal to report or indicate whether any particular thing built at all. The main goal was just showing tip docs. But a secondary goal was that changing cmd/godoc meant that cmd/godoc self-deployed with those code changes (or CSS, JS changes). |
|
@cnoellekb Are you planning on working on this? If so, I'm happy to be a reviewer for the CLs. Otherwise I can take this and you can be a reviewer. |
|
Change https://golang.org/cl/162908 mentions this issue: |
|
Change https://golang.org/cl/162909 mentions this issue: |
|
Change https://golang.org/cl/162914 mentions this issue: |
We want to be able to test cmd/tip changes on staging before pushing to production. This change adds configuration files to be used for the staging environment. Mirror the production environment, but use a staging-specific load balancer IP, domain, and autocert GCS bucket (golang-tip-dev-autocert). Also rename the existing production configuration files to mirror the pattern in other directories. This is especially important now that there are both production and staging configuration files. Updates golang/go#30232 Change-Id: I11c8cf643654d2c5bfa4add50f9ac8ca6771606b Reviewed-on: https://go-review.googlesource.com/c/162914 Reviewed-by: Brad Fitzpatrick <[email protected]>
|
Change https://golang.org/cl/177217 mentions this issue: |
The new x/website is built in module mode. Now that proxy.golang.org is available publicly, cmd/tip can start using it for fetching modules when building x/website. Also make a change to newServeMux so that httpsOnlyHandler is only used when HTTPS is turned on. That stops redirecting to HTTPS when HTTPS is not being served, thereby fixing HTTP-only local development mode. Updates golang/go#26872 Updates golang/go#30232 Updates golang/go#29206 Change-Id: If0382c45b9c99540adce3a894054730f5a7a9fdb Reviewed-on: https://go-review.googlesource.com/c/build/+/177217 Reviewed-by: Brad Fitzpatrick <[email protected]>
This is a tracking but to make sure the new x/website codebase also does tip.golang.org (which runs on GKE + uses autocert now)
/cc @cnoellekb @katiehockman @andybons @dmitshur
The text was updated successfully, but these errors were encountered: