Closed tarasis closed 1 year ago
afontenot
commented
1 year ago Not an expert, but my understanding is that a lot of asset compilation failures (which is what you're facing here) that don't have a clear error message (nothing after "compilation failed:") are the result of running out of memory. The build process takes quite a lot. Could that be the case here?
tarasis
commented
1 year ago Very possible. It's a 2GB machine with 1GB of Swap. It was getting awfully close on both. Will increase swap file size and try again.
dfloer
commented
1 year ago FWIW, I was trying to run docker-compose build from main at commit 302a58c2 and was getting the same error, but going back to tag v4.0.0rc2 (commit 5187e4e7) didn't have the issue. Similar setup, Archlinux with similar versions of docker (20.10.21).
dfloer
commented
1 year ago I can confirm that I ran out of memory on a VPS with 4GB of RAM and 512MB of swap on that step, and got that error.
ClearlyClaire
commented
1 year ago It indeed sounds like webpack running out of memory.
Annoyingly, when that happens, webpacker has a tendency to pretend it doesn't need to do anything on subsequent calls. One way to address that is to run RAILS_ENV=production bundle exec rails assets:clobber before retrying.
As for being actually able to build the assets, you have a few options:
public/packs)
diff --git a/config/webpack/production.js b/config/webpack/production.js
index 79dcebc7c4..47dcfae835 100644
--- a/config/webpack/production.js
+++ b/config/webpack/production.js
@@ -17,6 +17,7 @@ module.exports = merge(sharedConfig, {
devtool: 'source-map',
stats: 'normal',
bail: true,
diff --git a/config/webpack/production.js b/config/webpack/production.js
index 79dcebc7c4..4addad23b0 100644
--- a/config/webpack/production.js
+++ b/config/webpack/production.js
@@ -18,7 +18,7 @@ module.exports = merge(sharedConfig, {
stats: 'normal',
bail: true,
optimization: {Thanks @ClearlyClaire for the options. For doing the compile elsewhere is it as simple as copying the mastodon directory and docker directory and building remotely? Not something I've done before.
I bumped my swap from 1GB to 3GB, and left it to build while I slept. It seems to have completed okay although the compile took ages (67 minutes).
[+] Building 5656.7s (21/21) FINISHED
=> [internal] load build definition from Dockerfile 2.2s
=> => transferring dockerfile: 32B 0.8s
=> [internal] load .dockerignore 2.2s
=> => transferring context: 35B 0.7s
=> [internal] load metadata for docker.io/library/ubuntu:20.04 9.0s
=> [build-dep 1/7] FROM docker.io/library/ubuntu:20.04@sha256:450e066588f42ebe1551f3b1a535034b6aa46cd936fe7f2c6b0d72997ec61dbd 0.0s
=> [internal] load build context 3.4s
=> => transferring context: 454.95kB 3.3s
=> CACHED [build-dep 2/7] RUN echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections 0.0s
=> CACHED [build-dep 3/7] RUN ARCH= && dpkgArch="$(dpkg --print-architecture)" && case "${dpkgArch##*-}" in amd64) ARCH='x64';; ppc64el) ARCH='ppc64le';; 0.0s
=> CACHED [build-dep 4/7] RUN apt-get update && apt-get install -y --no-install-recommends build-essential bison libyaml-dev libgdbm-dev libreadline-dev libjemalloc 0.0s
=> CACHED [build-dep 5/7] RUN npm install -g npm@latest && npm install -g yarn && gem install bundler && apt-get update && apt-get install -y --no-install-recommends 0.0s
=> CACHED [build-dep 6/7] COPY Gemfile* package.json yarn.lock /opt/mastodon/ 0.0s
=> CACHED [build-dep 7/7] RUN cd /opt/mastodon && bundle config set --local deployment 'true' && bundle config set --local without 'development test' && bundle conf 0.0s
=> CACHED [stage-1 2/10] COPY --from=build-dep /opt/node /opt/node 0.0s
=> CACHED [stage-1 3/10] COPY --from=build-dep /opt/ruby /opt/ruby 0.0s
=> CACHED [stage-1 4/10] RUN apt-get update && echo "Etc/UTC" > /etc/localtime && apt-get install -y --no-install-recommends whois wget && addgroup --gid 991 mastodon 0.0s
=> CACHED [stage-1 5/10] RUN echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections 0.0s
=> CACHED [stage-1 6/10] RUN apt-get update && apt-get -y --no-install-recommends install libssl1.1 libpq5 imagemagick ffmpeg libjemalloc2 libicu66 libidn11 liby 0.0s
=> [stage-1 7/10] COPY --chown=mastodon:mastodon . /opt/mastodon 32.4s
=> [stage-1 8/10] COPY --from=build-dep --chown=mastodon:mastodon /opt/mastodon /opt/mastodon 643.7s
=> [stage-1 9/10] RUN cd ~ && OTP_SECRET=precompile_placeholder SECRET_KEY_BASE=precompile_placeholder rails assets:precompile && yarn cache clean 4063.5s
=> [stage-1 10/10] WORKDIR /opt/mastodon 1.4s
=> exporting to image 897.5s
=> => exporting layers 896.2s
=> => writing image sha256:ae4a59dfbf1317da8e7b767204789b01c0d4cda8f5326187f349081f4b0936b9 0.1s
=> => naming to docker.io/tootsuite/mastodon
Steps to reproduce the problem
I am upgrading from a running Docker install of 3.5.3
I did:
Expected behaviour
That the build completes
Actual behaviour
Build failed after 63 minutes with an ERROR [stage-1 9/10]. "failed to solve: executor failed running"
Detailed description
Specifications
Mastodon tag 4.0.0 Docker version 20.10.20, build 9fdeb9c3de & then Docker version 20.10.21, build baeda1f82a ARCH LINUX Latest.