Open Bug 1504996 Opened 7 years ago Updated 6 years ago

Investigate hosting Treeherder's UI on Netlify

Categories

(Tree Management :: Treeherder: Infrastructure, enhancement, P3)

Product:
Tree Management
Component:
Treeherder: Infrastructure
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: emorley, Unassigned)

References

(Blocks 1 open bug)

Details

Currently we serve the webpack-generated frontend static assets the same as requests to the API (via gunicorn+django+WhiteNoise running on Heroku). The advantages of this approach are: * atomic deploys of the frontend+backend * a single tool to learn/use (albeit multi-buildpack adds to complexity) * don't need to think about CORS The downsides to this approach are: * if web dyno request queuing times are high due to slow API requests, then end users can end up being served the generic Heroku HTTP 503 "app unavailable" page. If they had been served our static content instead, it could display more useful error messages and perform more graceful retries/backoff. * not using a CDN (so long round trip for users not near us-east), worsened by Heroku not supporting HTTP2 * complexity of trying to shoehorn two stacks (Node.js + Python) into one Heroku app * reduced parity with development (since we don't serve everything with gunicorn in development) * much harder to have "review apps" on PRs (compared to eg Netlify's PR preview feature) One possible alternative might be to: * use Netlify to serve Treeherder's frontend (eg from treeherder.net) * continue to use Heroku to serve the backend (but eventually moving it to be from eg api.treeherder.net) * have the UI make cross-origin requests to the API (after figuring out the necessary CORS pieces) Netlify also have a proxy feature which could be used to ease the transition: https://www.netlify.com/docs/redirects/#rewrites-and-proxying Doing this work would also set us up nicely for any potential future GCP move, since it would be one more piece that was decoupled.
Blocks: 1389572

I poked at this and it doesn't work out of the box.

We will need to use their Docker image and make it think that it is a Yarn project rather than a Python project (the requirements.txt file fools into it):
https://github.com/netlify/build-image

We will probably need to move node specific files under ui/ (or symlink them) and make their build system build from ui/

You can checkout the netlify branch if you're interested.

In the branch I moved all Js related files (e.g. .neutrinorc.js, package.json under the ui/ directory).
This is because Netlify's Docker image eagerly starts using the Python version from runtime.txt (It supports 3.6 not 3.7.2) and the requirements.txt files that are listed and fails to build.

You can see an initial deployment here:
https://5d6ec76f1a2e6460ae23930f--treeherder.netlify.com/#/jobs?repo=autoland

Here are just some notes of what I was trying locally to reproduce the environment (see official docs):

docker pull netlify/build:xenial
./test-tools/start-image.sh treeherder/ui/
# Inside the Docker container
NETLIFY_VERBOSE=true NODE_VERSION=10 NODE_ENV=production ; build yarn build
You need to log in before you can comment on or make changes to this bug.