The main point of Website-Publish+1 was to manually avoid
a race in Cloud Build when multiple commits land. But now
cmd/locktrigger takes care of that race automatically, so there
is little point to Website-Publish+1 now. Stop looking for it.
(If a commit landed without Website-Publish+1, it would still be
published with the next Website-Publish+1 commit, so it was
no real restriction on who can publish content.)
I considered adding a rule like "DO NOT PUBLISH" in a commit
message means not to publish the commit, but once it lands,
again the next publishable commit is going to publish all
previous commits, so even the possibility of landing such commits
puts the repo in a very fragile state.
Better not to support that idea at all.
Fixesgolang/go#36707.
Change-Id: Icfe3bcdb0003608ff84bb300c43b61b542236571
Reviewed-on: https://go-review.googlesource.com/c/website/+/368366
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
There are differences in the App Engine environment that
cannot be adequately simulated elsewhere. Although we do
the best we can with testing locally, there will always be
differences.
The old makefiles deployed the site, then ran a regression
test against it, and then promoted the tested version.
This change does the same. The testing has moved into the
web server proper so that it can test the handler directly and
thereby check things like the responses on different domains.
The go-app-deploy.sh now always deploys --no-promote,
only promoting after a self-test passes on the deployed site.
Unlike the old check which only applied to golang.org,
the new pre-promotion testing happens for all the sites.
Also factor out GoogleCN into internal/web, because we needed
to modify it (to avoid internal/webtest's requests being diagnosed
as coming from China) and there were too many copies.
Change-Id: I0cde0e2167df2332939908e716ddb6bf429f2565
Reviewed-on: https://go-review.googlesource.com/c/website/+/329250
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This app has been through a lot of evolution and has accumulated
a lot of cruft in the way it is deployed. We can simplify deployment
down to a short Cloud Build script and go back to regular App Engine
for execution.
Also remove the prod-vs-local distinction and the build tag complexity.
App Engine Flex doesn't let us have extant versions without at least
a couple dedicated VMs, and then it also imposes a limit of 20 VMs,
which makes it unsuitable for continuous deployment, where we can
rack up many versions in a short amount of time. Going back to
App Engine Standard is a better fit, since versions that aren't getting
traffic scale down to zero.
Using App Engine Standard also matches blog and go.dev,
which will help with the eventual merging of all these servers.
Change-Id: I35167b569327ad253b9d367d747072a269205b20
Reviewed-on: https://go-review.googlesource.com/c/website/+/323892
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
These deployment configs are meant to be run from Cloud Build.
They deploy a new version of the site on each commit,
using the commit date and hash to derive the app version.
If a commit is submitted with a Website-Publish+1 vote,
then the new version is promoted to be the live version of the site.
Otherwise the new version is left unpromoted, where it can be
manually inspected and potentially manually promoted,
or simply ignored and eventually automatically deleted.
golang.org will work this way too, after we move it off of Flex.
Change-Id: Iaddb3596276d5cfbf18aa67f210fcd33f323d9d5
Reviewed-on: https://go-review.googlesource.com/c/website/+/324511
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Website-Publish: Russ Cox <rsc@golang.org>
Russ Cox