Add a /version handler to serve information about the playground Go
version.
Also consolidate writing JSON responses into a common helper.
Change-Id: I1bb3de4c23320eb58306c93a51dbe9ae5176382d
Reviewed-on: https://go-review.googlesource.com/c/playground/+/365854
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
With the gotip playground we may want to swap out examples with greater
frequency, to demonstrate new features at Go tip. Make this easier by
deriving examples directly from the examples directory via a new
examplesHandler type. This also enables having dynamic content for
hello.txt, which depends on the value of runtime.GoVersion().
This will impact the non-tip playground in a few ways:
- We will now pre-load examples at server start up.
- Examples will be sorted by their title (with the exception of Hello,
playground, which is always first).
- We will set a CORS header for examples. This was added for consistency
with other handlers, and seems harmless.
Generalize TestShare to TestServer, and use it to test the examples
handler.
Add a single gotip example demonstrating generics.
Updates golang/go#48517
Change-Id: I7ab58eb391829d581f7aeae95c291666be5718b9
Reviewed-on: https://go-review.googlesource.com/c/playground/+/364374
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Attempt to clearly label the Go tip playground as a development build,
and surface the version string.
For some reason I had to install git in the build-playground phase of
the Docker build, to avoid errors from the Go command. I'm not sure why
this is, but it seems harmless.
For golang/go#48517
Change-Id: I35b150686c9f177d76024cc38ff62cb8785525e0
Reviewed-on: https://go-review.googlesource.com/c/playground/+/363980
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
appengine.IsAppEngine mistakenly returns false, as it relies on the app
being built with the appenginevm build constraint. This is not set,
as we're supplying our own Docker image.
The playground is always running either locally or on appengine. We can
rely on metadata.OnGCE being correct.
Other calls that are made to the appengine library either use the
metadata server or environment variables, and do not rely on a
constraint being set. They also panic if the metadata server is
unavailable.
For golang/go#44822
Change-Id: I1de5fda4bfd1e909f1fd54cc44770525827a9c1a
Reviewed-on: https://go-review.googlesource.com/c/playground/+/303469
Trust: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This change adds a latency distribution for the build&vet stage, the vet
stage, and the run stage of a snippet handled by the compile handler.
For golang/go#44822
Change-Id: Icedce87492afadd6041efb05e6f0ed3cd12a01ba
Reviewed-on: https://go-review.googlesource.com/c/playground/+/302770
Trust: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This change avoids cascading sandbox backend failures to the frontend
instances.
The timeout TODO is safe to remove as we now pass in the request context
for cancellation, and sandboxBuild has its own build timeout.
Updates golang/go#25224
Updates golang/go#38530
Change-Id: If892f86bad08c55429b6ebab768b83c5d7621cf1
Reviewed-on: https://go-review.googlesource.com/c/playground/+/229677
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This changes the Playground to stop storing build and run timeout
responses in the cache. These responses could get cached when the
Playground was unhealthy, leaving some trivial snippets to be cached
incorrectly, confusing users.
Adds testing for our caching logic.
Updates golang/go#38546
Updates golang/go#38576
Change-Id: Idd2106d673162d9eea8536fe2433f74c23ed6e8a
Reviewed-on: https://go-review.googlesource.com/c/playground/+/229307
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
As a way to document the playground's tricks, this change adds
a dropdown of examples to the right of the "Share" button. They
are as follows:
- Hello, playground (default)
- Tests
- Multiple files
- Display image
- Sleep
- Clear
Fixesgolang/go#32294.
Change-Id: I6cdd54714d5638a932b2d392db1ea888468f5cec
Reviewed-on: https://go-review.googlesource.com/c/playground/+/216359
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
handleVet and handleCompile methods were almost indentical.
The only differences were the prefix for the cache key and
the function which executed command and made a response struct.
This changes introduces the commandHandler function that
returns an HTTP handler specified by the cache prefix and
command function (cmdFunc).
vetCheck and compileAndRun are those command functions.
Fixesgolang/go#24535.
Change-Id: I4eaa5364cd4ee5f778c5b5b272b74b23e4caef7c
Reviewed-on: https://go-review.googlesource.com/112795
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Playground runs a program through the "go vet" command and
displays found errors before the output of a program.
Vet check is performed for successfully compiled program only.
Vet errors are highlighted in the code editor.
Depends on the CL 107455.
Fixesgolang/go#7597Fixesgolang/go#24576
Change-Id: I316a4a66e701f2a179aeafc82efc8fe31a543c11
Reviewed-on: https://go-review.googlesource.com/100776
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Since frontend was moved to the flex runtime, there is no longer
a reason to keep the two separate. Consolidate the two into one
service to reduce deployment complexity.
Change-Id: Ie64c17e1833ed94ac8bff7381963f683d824ca5d
Reviewed-on: https://go-review.googlesource.com/85456
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Robert Findley
Alexander Rakoczy
smasher164
Yury Smolsky
Andrew Bonventre