-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Frontend
You need npm
, install dependencies using npm install
.
You can then do npm start
to run a static file server at port 3000 that
watches the source files. A separate mock backend process also needs to be
started to handle all backend API requests. This can be started in a separate
shell by running npm run mock:api
. The mock backend includes some sample
data to showcase many of the UI interactions.
You can do npm run build
to build the frontend code for production, which
creates a ./build directory with the minified bundle. You can test this bundle
using server/server.js
(first build the server by running npm run build
inside the server directory. Note you need to have an API server running, which
you can then feed its address (host + port) as environment variables into
server.js
. See the usage instructions in that file for more.
You can also do npm run docker
if you have Docker installed to build an
image containing the production bundle and the server pieces. In order to run
this image, you'll need to port forward 3000, and pass the environment
variables ML_PIPELINE_SERVICE_HOST
and
ML_PIPELINE_SERVICE_PORT
with the details of the API server, which
you can run using npm run mock:api
separately.
The frontend part of the project maintains three types of tests:
We try to maintain good coverage of the code, and new code should always
include tests. You can run the test suite from the frontend directory
by running npm test
.
We use backstop.js to capture screenshots of the basic code paths, in order
to make sure there are no visual regressions. Currently these are run
and verified manually, due to the general brittleness of visual comparison
techniques cross-platform. You can run the suite by running npm run vr-test
in the frontend directory, which should show the diff report in a browser
window. You can run npm run vr-approve
to copy the changes to the tracked
golden images.
These tests are meant to be run against a Kubernetes cluster, since they test the end to end behavior of the UI against the actual backend. They use webdriver.io to start a browser and perform regular user operations such as uploading a pipeline, creating an experiment out of it, then a run, and validating the run's outputs and logs. You can find these in the test directory under frontend-integration-tests.