mix assets.deploy fails in Alpine Docker Env

[hukl]

Versions: nodejs: 16.13 phoenix: 1.6.0 elixir: 1.12.3 esbuild: 0.3.4 docker: 20.10.6

We're using the elixir:1.12.3-alpine docker image to assemble our release. Up until recently this worked fine but now we're getting the following mysterious error code when running

> mix assets.deploy
** (Mix) `mix esbuild default --minify` exited with 8

On our dev machines, this works fine with the same phoenix, elixir, esbuild and nodejs versions and we haven't changed the contents of the docker image. The only possible difference that is left after our long debugging session is that the docker image which works, was built and cached by an earlier docker version. But without knowing what exited with 8 means, we're stuck at this point.

Our docker file looks as follows:

FROM elixir:1.12.3-alpine
LABEL maintainer "hukl"

ENV PHOENIX_VERSION=1.6.0
ENV POSTGRES_HOST=host.docker.internal
ENV MIX_ENV=container

RUN apk add git bash curl wget make gcc alpine-sdk graphicsmagick
RUN apk add nodejs npm --repository=http://dl-cdn.alpinelinux.org/alpine/edge/main

RUN mix local.hex --force && \
    mix local.rebar --force
WORKDIR /app

COPY . .
RUN mix deps.get
RUN mix deps.compile
RUN mix compile
RUN npm install --prefix ./assets
RUN mix assets.deploy # this is where the error happens and which works locally
…

Any clues would be appreciated!

[hukl]

The reason was that COPY also copied the local _build folder which contained the esbuild executable which was of the type esbuild: Mach-O 64-bit executable arm64 and therefor didn't run in our linux docker image. Would've still been great to have a more descriptive error ;)

[cw789]

It's difficult to get a descriptive error for this case. If the wrong esbuild binary thought for a different OS architecture is present, the call to esbuild will possibly just fail (or even work and then fail).

But I understand if one stumble across this problem it's difficult to find the cause.

---

The current esbuild implementation does not have any information for which OS architecture the present esbuild binary is for.

The only solution I could think of, we would need to save the esbuild binary with the OS architecture information attached. → _build/esbuild-linux-64

Then at runtime always check the target and call the binary with it.

@josevalim May I ask you for your opinion? Is it worth it to go this way?

[josevalim]

@cw789 I think saving it as esbuild-linux64 doesn't hurt and we already have the logic to compute the architecture anyway. Can you please send a PR? :)

[hukl]

Oh I'm glad filing this was still useful :)

[cw789]

Can you please send a PR? :)

Sure, I love to do so.

Oh I'm glad filing this was still useful :)

Of course it is. Thanks. Give me some time and we both won't stumble again over this problem.