build never finishes in Docker 3.3.3 but works in Docker 3.2.2

[romansky]

Steps to reproduce the behavior

cc docker/buildx#614

build_issue.tar.gz

1. use latest version (3.3.3)
2. run DOCKER_BUILDKIT=1 docker build . or docker build .

Some strange things that I observed, if cp command in vendor.sh is commented out, issue does not happen, if you comment-in line 16 in Dockerfile and comment out line 17, issue does not happen.. No idea how to debug further..

If using 3.2.2 there is no issue..

[dawnmist]

Thank you for the repro!

First issue: there is no browserslist section in your package.json file. React scripts 2+ requires this to be present, and will stop building with a prompt message to add it if it is not present. The section suggested by React scripts is:

  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }

Splitting the RUN line 17 of your Dockerfile into two separate RUN commands then builds and completes. This at least gives a work-around for getting the build working again until you can identify what the real problem is.

Trying to debug it from inside the docker environment, it appears that the build:

• generates the config for webpack <== this step is what react-app-rewired modifies
• creates the build, build/css and build/img directories <== part of the Webpack Copy files plugin I believe
• does the copy of the image file from public/img/login_visual.png to build/img/login_visual.png <== Webpack Copy files
• then hangs and doesn't progress any further <== the build/js directory is not being created, nor is the index.html file, nor any compiled files.

That puts the issue into react-script's build process somewhere (as it occurs after react-app-rewired has made any modifications and in your repro case there were no actual modifications being made), but it's triggered by the use of the sourcing of the vendor.sh script in the same shell as the build.

One question I did have - has the copy command that is in the vendor.sh script always been there? When you run '. ./vendor.sh' it "sources" the script rather than running it, which I've normally only seen when setting environment variables but not when having actual commands needing to be executed in the script. I would not have expected the '. ' prior to the './vendor.sh' for a script to be run - but that may simply be me not having been exposed to that type of usage before. My main reason for mentioning/focusing on it is that it appears that the build may be hanging during the copying of the public files across to the build directory, and your own comments where if you comment out the cp line in the vendor.sh file it stops it having troubles...as if maybe it is changing the cp command by mistake somehow in the shell that it is being run within.

I used the instructions here to be able to view what was going on with the browserlist, and then how far through the build of the site react-scripts was getting/what files were actually being created under the build directory: https://pythonspeed.com/articles/debugging-docker-build/

[romansky]

@dawnmist thank you for the detailed step by step of what is going on there, very insightful!

You are correct in your expecting of my usage of the ".", my full vendor.sh does set environment variables and according to the vendor specified also copies over vendor specific artifacts (white-labeling kind of thing), when submitting this issue I made sure to make it as minimal as possible so there's no noise.

if you run the same thing with Docker 3.2.2 everything works as expected, so it just breaks after update to 3.3.3, strangely enough!

I have a workaround currently in place (I believe your workaround would also work), but this still seems like some kind of a regression introduced by one of the 3.3.* updates, hopefully this can help someone find this regression