tempRepoDir used path.Join (not filepath.Join) and url.PathEscape,
which aren't suited for file path manipulation, causing git clone
to fail to clone the repository on Windows. Fix that.
Since there's only one repoURL constant, simplify the tempRepoDir
function to be one variable alongside repoURL.
Change-Id: I74d0f78a1d79a0456444eaf2a3f4479d383503e9
Reviewed-on: https://go-review.googlesource.com/c/build/+/501196
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Both work but go.dev is newer and shorter.
For golang/go#59741.
Change-Id: I5f65d67bc997058860be77373e3a7952565acc10
Reviewed-on: https://go-review.googlesource.com/c/build/+/486956
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Dependencies from the 3 modules were combined by essentially taking the
highest version from each. The following sequence reproduces the change
to the top-level go.mod file:
go get cloud.google.com/go/pubsub@v1.26.0
rm cloudfns/*/go.mod
go mod tidy
In order to deploy cloud functions now, the sequence of steps ends up
recreating the nested modules in the local tree by reusing dependency
versions selected in the top-level root module, and 'go mod tidy'-ing
away all the unused modules. This way we end up maintaining two fewer
go.mod files.
While here, update the Go runtime used by the Cloud Functions to 1.20
and use io instead of io/ioutil.
Fixesgolang/go#59741.
Change-Id: Icd1c1b388f648dbb13fbea5371860cc96521a9d6
Reviewed-on: https://go-review.googlesource.com/c/build/+/486955
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
go get cloud.google.com/go/pubsub@v1.26.0
go mod tidy
This brings in loong64 support.
Change-Id: Iff5905f5aa866b240832abf76ce97a4a8763e8f7
Reviewed-on: https://go-review.googlesource.com/c/build/+/453456
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This function was actively used a few years ago, but by now it's not
serving any purpose. If it (or a modified version thereof) becomes
needed again, it's easy to re-add. In the meantime, delete its code
to reduce x/build maintenance costs slightly.
For golang/go#51867.
Change-Id: I4962cc5a6384541ca4f38003565b2cdc218c0c51
Reviewed-on: https://go-review.googlesource.com/c/build/+/396477
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
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>
Dmitri Shuralyov
Guoqi Chen
Bryan C. Mills
Alexander Rakoczy
Brad Fitzpatrick
Andrew Bonventre