BUG: cannot docker-compose up anymore

[mfortini]

devita_website    | <s> [webpack.Progress] 98% after emitting
devita_website    | <s> [webpack.Progress] 100% 
devita_website    | 
devita_website    | node:events:504
devita_website    |       throw er; // Unhandled 'error' event
devita_website    |       ^
devita_website    | 
devita_website    | Error: write EPIPE
devita_website    |     at afterWriteDispatched (node:internal/stream_base_commons:160:15)
devita_website    |     at writeGeneric (node:internal/stream_base_commons:151:3)
devita_website    |     at Socket._writeGeneric (node:net:795:11)
devita_website    |     at Socket._write (node:net:807:8)
devita_website    |     at writeOrBuffer (node:internal/streams/writable:389:12)
devita_website    |     at _write (node:internal/streams/writable:330:10)
devita_website    |     at Socket.Writable.write (node:internal/streams/writable:334:10)
devita_website    |     at console.value (node:internal/console/constructor:286:16)
devita_website    |     at console.log (node:internal/console/constructor:360:26)
devita_website    |     at LogLevel.info (/usr/src/developers.italia.it/node_modules/webpack-log/src/loglevel/PrefixFactory.js:55:7)
devita_website    |     at Object.reporter (/usr/src/developers.italia.it/node_modules/webpack-dev-middleware/lib/reporter.js:17:13)
devita_website    |     at /usr/src/developers.italia.it/node_modules/webpack-dev-middleware/lib/context.js:42:23
devita_website    |     at processTicksAndRejections (node:internal/process/task_queues:78:11)
devita_website    | Emitted 'error' event on Socket instance at:
devita_website    |     at emitErrorNT (node:internal/streams/destroy:157:8)
devita_website    |     at emitErrorCloseNT (node:internal/streams/destroy:122:3)
devita_website    |     at processTicksAndRejections (node:internal/process/task_queues:83:21) {
devita_website    |   errno: -32,
devita_website    |   code: 'EPIPE',
devita_website    |   syscall: 'write'
devita_website    | }
devita_website    | make: *** [Makefile:31: local] Error 1
devita_website exited with code 2

[mfortini]

May be related to facebook/create-react-app#9077 (comment)

[mfortini]

Above solution with .dockerignore works for me

[bfabio]

@mfortini that's probably the right solution

[zukka77]

I had the same problem, the .dockerignore workaround didn't work for me.
Thanks to @libremente I tried this #1253 and this did the trick :)

[ruphy]

@bfabio can we merge #1253 ?

[bfabio]

@ruphy sure

[zukka77]

Today i started "fresh" and I had to put bundle config set path vendor/ in some more place in the Makefile, this works for me:

bundle-install: bundle-setup
	bundle config set path vendor/
	bundle install

bundle-install-deployment: bundle-setup
	bundle config set path vendor/
	bundle install --deployment

test:
	npm run lint
	npm run test
	scripts/pa11y.sh
	bundle exec htmlproofer ./_site --assume-extension --check-html --allow-hash-href --empty-alt-ignore --only-4xx --disable-external

local:
	bundle config set path vendor/
	npx webpack-dev-server --config webpack.dev.js --color --progress -d --host 0.0.0.0 | bundle exec jekyll serve --livereload --incremental --host=0.0.0.0 --trace

[bfabio]

@zukka77 is that with current main?

[zukka77]

@bfabio no, it's here https://github.com/zukka77/developers.italia.it/blob/container-podman-friendly/Makefile it's part of this PR #1303 maybe I should have keep it separated 🤔

[bfabio]

@zukka77 I meant: do you still have trouble building the site with current main?

[zukka77]

@bfabio with the one in the current main didn't work, I had to add bundle config set path vendor/ in the other two places other than local (like in the Makefile I linked on my tree).
I'm not sure if it is necessary in both places though.

[ChrisUser]

This morning I came across the same issue and managed to fix it by adding bundle config set path vendor/ to both bundle-install and bundle-install-deployment as suggested by @zukka77.
It seems that you need to place the command in both places to make it work.

I'm working on a fork made from the current master branch, with Docker Desktop v4.17.0 and Docker Compose v2.15.1 both installed on a Windows 10 machine.

[bfabio]

I'll lay some background info, because it's complicated™.

There was a time when the build used to be quite inscrutable and we refactored it to remove a lot of complexity and randomness, yes this is the simplified version of it 😢

Judging purely by this experience if feel like it's a zero-sum game, where pulling the blanket from one side only uncovers the other, this because the Makefile and the build in general has to account for different environments and their subvariants:

• The local one
  • with Docker
    • Docker on SELinux (fe. Fedora)
    • Docker on AppArmor (fe. Debian)
  • with Podman
  • with all the combination above if you ran bundle install outside the container and it created a .bundle/config there
• The GitHub enviroment in production
• The Vercel environment for previews

There are a lot tweaks, some obvious and some less obvious but, in general they are time consuming and need to be tested on all those envs. That, in addition to having the preview on PRs as a way to bypass all the problems when it comes to small changes (which are the majority recently), has led to deprioritizing this issue.

The root issue is having two different runtimes though. Jekyll served us well but I think the real solution is #1007 as the site got more dynamic, but of course it's way more work.

For now, I believe we can try and do it step by step, putting bundle config set path vendor/ everywhere seems like a good start because it makes sense - I kinda remember that there's something subtle there, but it has been a while since I looked into it - let's see if any of those environments break.

We can split @zukka77's (thanks!) work zukka77@a5e1794 into three PRs:

1. The one with the explicit registry docker.io: its backwards compatible and we can merge it immediately
2. TOW the changes to ElasticSearch: same as above
3. TOW bundle config set path vendor/ everywhere: we can merge it immediately as well and see how it goes

I'd rather open a new issue for the removal of the unprivileged user, I'm not 100% sure about it because it would be a step back for Docker.