Also consistently deduplicate Env entries, mainly to reduce confusion
when reading logs.
This change is probably larger than what is strictly needed to fix the
issue, but it seemed simpler than trying to figure out which of the
many calls to exec.Command in the module are actually relevant.
(It also provides some useful case studies for possible additions to
the Go standard library.)
For golang/go#33598
Change-Id: Ia2bce4549e4a71b56fb497e3df093f79fbcf7f29
Reviewed-on: https://go-review.googlesource.com/c/build/+/353549
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Prior to CL 230637, this cloud function was targeting the Go 1.11
runtime, which implicitly¹ set the GCP_PROJECT environment variable.
That no longer happens with the newer Go runtime², so set the same
variable explicitly, otherwise publishing to the topic fails.
Remove a defer r.Body.Close() line; the http.Request body is closed
by the http.Server, http.Handler does not need to.
Also update the version of pubsub package to the latest. It isn't
needed to fix the problem, but it has already been tested during
debugging, so it's inexpensive to include.
A future enhancement is to factor out the pubsub client creation
to happen once per function instance rather than per invocation³,
and use metadata.ProjectID instead of needing an explicit env var.
¹ https://cloud.google.com/functions/docs/env-var#nodejs_8_python_37_and_go_111
² https://cloud.google.com/functions/docs/env-var#newer_runtimes
³ https://cloud.google.com/functions/docs/concepts/go-runtime#one-time_initializationFixesgolang/go#44948.
Change-Id: I03fd66c7fb784cef24c5759b45cb7c10ed17ee6a
Reviewed-on: https://go-review.googlesource.com/c/build/+/302549
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This makes the deploy into something that can be executed without
the need to seek external context on where the secrets are kept.
It's especially helpful since we deploy cloud functions less
frequently than many other services.
A future change can explore removing secrets from the environment,
preferring to have the cloud function access secrets directly from
Secret Manager.
Updates golang/go#37171.
Change-Id: I1b1468c6f02d45b764f65396027d9bdca69ac5e4
Reviewed-on: https://go-review.googlesource.com/c/build/+/300230
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Some of README.md files were initially generated by update-readmes.go,
but later had some additional information appended. Re-running update-
readmes.go blasts away those changes, and requires manually reverting
the deletions. This makes it expensive to re-run update-readmes.go to
add new READMEs or update existing ones.
Solve this problem by adding support for a special "<!-- End of auto-
generated section -->" comment and making update-readmes.go preserve
any content after it.
After this change, re-running update-readmes.go produces a zero diff.
Also set the working directory when using build.Import so that packages
inside nested modules work okay.
Add the missing first word 'Package' to ./internal/datastore/fake doc.
Change-Id: If7ba92a297eebeec8029d48d760acb1daa7f263e
Reviewed-on: https://go-review.googlesource.com/c/build/+/300229
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
We're running on an outdated version of Go, and should not be.
Change-Id: I650c9d74cf230c2c24939c79a270040026a489ca
Reviewed-on: https://go-review.googlesource.com/c/build/+/230637
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
To do historical analysis, it is helpful to have a corpus of
events data from GitHub. Store all GitHub events in a GCS
bucket until golang/go#29396 is fixed.
Updates golang/go#29396
Change-Id: Ia0172db93e019a8d6ab4ccf6e195f3a3e15583bd
Reviewed-on: https://go-review.googlesource.com/c/build/+/199638
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change introduces two cloud functions: wikiwebhook and
sendwikidiff. The former handles GitHub Wiki change events
sent over HTTP and enqueues them on a pubsub topic for the
latter to pick up. sendwikidiff then checks out the wiki
repo and sends an email with the diff of the change to
golang-wikichanges@.
The reason it is split into two functions is due to GitHub’s
timeout limit on webhook handlers (ten seconds). In testing,
a cold boot of a function that does everything described
above would sometimes hit that limit.
Updates golang/go#27313
Change-Id: I1974e1434c7003482df724d6ea3b537e22231c36
Reviewed-on: https://go-review.googlesource.com/c/158642
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>