You can run these yourself using the -perf flag, e.g.
> noms serve &
> go test -v -perf http://localhost:8000 ./samples/go/csv/csv-import
> noms ds http://localhost:8000
Though you'll need to go-get github.com/attic-labs/testdata.
Note that all of this only records test results, it doesn't have any
concept of failing perf (unless test assertsions themselves fail). It
will be the job of some other Noms client (work in progress) to do that.
I will be setting this up to run continuously momentarily.
This is necessary to handle x-noms-vers header from browsers.
Adds x-noms-vers header to all responses from demo-server and 'noms serve'.
Fixes#1984. Fixes#1991.
This adds some a basic integration tests for sample/js/{counter,fs}.
It work pretty much like this:
- Run `npm install`
- Do setup (good place to initialize the database) (optional).
- Start a http store from go.
- Run `node . <args...>`. The IntegrationTestSuite has convenience
methods to get the spec.
- Do teardown, which is a good time to check the output and the current state of the db (optional).
Towards #1888
ChunkStores provide a Version() method so that anyone directly
using a ChunkStore (e.g. BatchStoreAdaptor) can retrieve and
check the version of the underlying store.
remoteDatabaseServer checks the version of the ChunkStore it's
backed by at startup, and then provides that version as an HTTP
header to all clients. In Go, httpBatchStore checks this header
anytime it gets a response from the server and bails if there's
version skew.
In Go, the responsibility for checking whether the running code and
the data being accessed lies with the BatchStore layer. In JS, there
is code in fetch.js that checks the header mentioned above.
Towards #1561
Erik Arvidsson