What does this PR do?
Three things:
root
Many thanks to @luna for instigating this investigation.
Bring our Dockerfile closer to upstream's
We really don't need the 3 stages (native build, target build, runner), and I'm pretty sure upstream doesn't need them either (people who actually know Docker can probably correct me here, but I don't think you can run an arm64
image on a x86_64
machine… so BUILDPLATFORM
and TARGETPLATFORM
can't be that different), so I have not copied that bit.
Also, our images are based on Alpine, upstream's on Debian, and I see no reason to switch.
Still, we can definitely reduce the differences between our Dockerfiles.
Make sure the container image contains the correct dependencies
Our Dockerfile ran pnpm i
without the --frozen-lockfile
argument, which resulted in the installation of potentially different versions; this was done because after running trim-deps.mjs
the lockfile was no longer valid. But pnpm prune
fixes that, without touching the versions, so now we can have our dependencies trimmed, and still keep the correct versions.
NOTE: I think trimming deps saves us only about 100KB, so we may just… not do it.
Don't run as root
As a side-effect of staying closer to upstream, we should run as a non-privileged user. Even if root
inside the container is not the superuser of the host, it can still read and write everywhere, and Sharkey doesn't need that.
Contribution Guidelines By submitting this merge request, you agree to follow our Contribution Guidelines
NOTE: I have tested that it builds, I have not tested that it runs!!