Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/talks: cannot deploy to GAE using gcloud app deploy #28080

Closed
andybons opened this issue Oct 8, 2018 · 6 comments
Closed

x/talks: cannot deploy to GAE using gcloud app deploy #28080

andybons opened this issue Oct 8, 2018 · 6 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@andybons
Copy link
Member

andybons commented Oct 8, 2018

App Engine requires that the Go files be in the same directory as app.yaml, but the current instructions say to copy the present/ dir from x/tools/cmd/ into the root of the x/talks repo. Since that still leaves no Go source files in the same directory as app.yaml it fails with: no buildable Go source files in $GOPATH/src/golang.org/x/talks

Plan is to merge App Engine and "local" logic into one binary without build tags, then run it on GAE Flex.

/cc @bradfitz @dmitshur

@andybons andybons added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 8, 2018
@andybons andybons added this to the Unreleased milestone Oct 8, 2018
@andybons andybons self-assigned this Oct 8, 2018
@bradfitz
Copy link
Contributor

bradfitz commented Oct 8, 2018

When did this break?

@andybons
Copy link
Member Author

andybons commented Oct 8, 2018

At least before summer. The same thing happened to the blog and it was easy enough to move the go files up a directory so they were in the same place as app.yaml. x/talks just hasn't been deployed in a while.

@dmitshur
Copy link
Contributor

dmitshur commented Oct 8, 2018

merge App Engine and "local" logic into one binary without build tags

🎉 👍

@gopherbot
Copy link

Change https://golang.org/cl/140838 mentions this issue: x/tools/playground: set content-type header on non-appengine builds

@gopherbot
Copy link

Change https://golang.org/cl/140841 mentions this issue: x/tools/cmd/present: merge appengine and non-appengine files

gopherbot pushed a commit to golang/tools that referenced this issue Oct 10, 2018
Currently, when a POST request is made using code with build tag
+build !appengine it doesn't set the content-type header passed
to the function. This was breaking the case where a url-encoded
body (a code snippet's body and protocol version) was being POSTed
to golang.org/compile since it never set the content-type of the
request and the corresponding form values parsed out were empty as
a result.

Update golang/go#28080

Change-Id: I677ca01b2f5aecedbd13d1faa7a838ddc0199244
Reviewed-on: https://go-review.googlesource.com/c/140838
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
gopherbot pushed a commit to golang/tools that referenced this issue Oct 10, 2018
Without changing the behavior of the present command for local
usage (using the local socket for running examples, defaulting to
the current directory for all content). Add flags and set them to
the appropriate values if running on App Engine.

Notably, since the Go files must be in the same directory as
app.yaml, the content root must be ./content/ to avoid listing
the present source files.

It also defaults to running example snippets via the HTTPTransport
(https://play.golang.org/compile) instead of locally when on App
Engine.

There are also some small cleanup code changes.

Update golang/go#28080

Change-Id: I40bb7923107614f88d2bfdffd34a824d4bacb3a1
Reviewed-on: https://go-review.googlesource.com/c/140841
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
@gopherbot
Copy link

Change https://golang.org/cl/141317 mentions this issue: talks: update repo to be deployable on App Engine

@golang golang locked and limited conversation to collaborators Oct 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants