bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Use multi-stage builds to avoid manual baking in on NodeJS stuff



11 months ago
9 months ago


(Reporter: peterbe, Unassigned)


Firefox Tracking Flags

(Not tracked)



Comment 1

11 months ago
There's got to be an easier way. The Node (and yarn) built in the main Dockerfile (today) is there purely for eventually running the `yarn run build` post-test in Circle for the sake of building artifacts to ship. 
Why can't we have a standalone Docker file dedicated to ONLY installing node + yarn and running `yarn run build`. Once built you can extract the files within out and put them on whatever host runs nginx. Or something. 

For localdev, there's the Dockerfile.frontend [0] which is neat but it's use is run the app server, not build. Couldn't we have something similar just for building the static assets? 

[0] https://github.com/mozilla-services/tecken/blob/master/Dockerfile.frontend
Flags: needinfo?(miles)

Comment 2

11 months ago
I'm such a novice at this but I was thinking something like this: Consider this file: https://gist.github.com/peterbe/cea30a9028f81019d7ba71afe5b09e95

$ docker build -f Dockerfile.buildfrontend .

That actually builds a node image, installs yarn and builds the static files. 
Now they're inside the container but after it finishes, I suspect, the container is immediately destroyed. If only there was a way to copy the files out of there and put them somewhere sane before it's destroyed. 

Granted I'm perhaps not understanding the whole deployment process beyond the basics of CI.
There's a lot to do with regards to cleaning up the tecken build process. In my opinion, the ideal state would be:
  - a single container that can be be built as simply as "docker build" that includes both python and node dependencies (via multi-stage build) fully ready for deployment
  - no separately built container for dev, instead use environment vars in docker-compose.yml, use entrypoint to override cmd in the dockerfile if needed
  - no external build scripts or makefile directives needed, anything special should be in either docker-compose.yml for dev purposes or in circle.yml

  - if we build the static frontend files every time ci builds will be a bit slower

I'm going to see if I can make some headway on this.
Flags: needinfo?(miles)

Comment 4

9 months ago
The PR is https://github.com/mozilla-services/tecken/pull/374

The current status is, I believe, that that PR works locally but fails in Circle. And we're not sure why yet.

Comment 5

9 months ago
Landed now.
Last Resolved: 9 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.