parcel-cache from dev environment leaks into docker build

[jennifer-richards]

What happened?

On a freshly built set of docker images, many javascript tests failed with errors like

======================================================================
FAIL: test_replace_proceedings_material_shows_correct_default (ietf.meeting.tests_js.ProceedingsMaterialTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/workspace/ietf/utils/jstest.py", line 91, in tearDown
    self.assertEqual("", msg)
AssertionError: '' != 'SEVERE: http://localhost:60355/static/iet[1415 chars]t"\n'
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 289 WebSocket connection to 'ws://localhost:1234/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 340:16 undefined
+ WARNING: http://localhost:60355/static/ietf/js/ietf.js 343:16 "[parcel] 🚨 Connection to the HMR server was lost"
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 289 WebSocket connection to 'ws://localhost:1234/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 340:16 undefined
+ WARNING: http://localhost:60355/static/ietf/js/ietf.js 343:16 "[parcel] 🚨 Connection to the HMR server was lost"
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 289 WebSocket connection to 'ws://localhost:1234/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 340:16 undefined
+ WARNING: http://localhost:60355/static/ietf/js/ietf.js 343:16 "[parcel] 🚨 Connection to the HMR server was lost"
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 289 WebSocket connection to 'ws://localhost:1234/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED
+ SEVERE: http://localhost:60355/static/ietf/js/ietf.js 340:16 undefined
+ WARNING: http://localhost:60355/static/ietf/js/ietf.js 343:16 "[parcel] 🚨 Connection to the HMR server was lost"

The WebSocket errors are a side effect of having run npx parcel watch while doing development before building the docker images. In that mode, parcel monitors its inputs for changes, then rebuilds and uses a WebSocket connection to notify the browser to reload its assets.

When called as npx parcel build afterwards, parcel is not smart enough to ignore the cached code that is involved in that connection. The prepackaged assets on the docker image expect to communicate with parcel over a WebSocket.

Working around this is as simple as running npx parcel build in the docker container once built, because it has its own empty .parcel-cache mounted from a volume. Apparently the host .parcel-cache is still in use while docker is building the app image. The build process should either clear the cache or otherwise ignore the existing cache contents.

What browser(s) are you seeing the problem on?

Not Applicable

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[NGPixel]

Parcel is never used while building the dev image. Only the package.json is copied and the NPM dependencies are installed.

The .parcel-cache would only be mapped when running the container. One solution could be to always purge this directory during the init script.

[jennifer-richards]

Ah, I think I figured out what happened. On my system, the npx parcel build that happens when starting up the container fails because of a permissions problem. The .parcel-cache is owned by root, but because npm runs as the working directory's owner, it does not have permission to write there. Because that failed, my initial test run was using whatever assets had been lying around from the last parcel build outside the container.

I don't think #3765 will help with this - if we want it for its own sake, I'm happy to merge it, but I don't think starting the container will necessarily align with a need to purge the cache.

Maybe running chown -R <uid of /workspace owner> /workspace before running parcel in the container is the right thing to do instead?