This "rebases" our application images off of the new Ruby base image
added in #19632, and fixes numerous problems and quirks with how the
images were built along the way. Notably:
- Issues where layers attempted to delete files in prior layers have
been resolved (this caused build failures on some Docker filesystem
drivers, notably overlay2).
- Bundler is no longer allowed to deviate from or modify the lockfile
(`BUNDLE_FROZEN` is now `true`).
- `git(1)` is no longer required to live inside the container and `.git`
is no longer required to be copied into the Docker build context, as
these were only used to calculate `FOREM_BUILD_SHA`, which is now
passed in as a Build Argument to the container build context.
- The entire source tree is no longer `chmod` in one giant swing, which
ran so long on my system (as just one example) that I gave up after
15-20 minutes and issued it a `SIGTERM`. Instead, `COPY --chown` is
used more heavily and ensures the `APP_USER` will have access to the
requisite files.
This new container image appears to build successfully for
`linux/arm64`, which refs (but does not complete) #19626. Currently,
such builds aren't automated , and must be built on a developer
workstation. For example:
```sh
docker buildx build --platform linux/amd64,linux/arm64 -f Containerfile . -t ghcr.io/forem/forem:klardotsh-test --push --build-arg VCS_REF=$(git rev-parse --short HEAD)
```
In the meantime, the existing `linux/amd64`-only BuildKite scripts have
been updated to allow this PR to merge as a separate unit, and CI
refactors to enable the multiarch builds of `linux/arm64,linux/amd64`
can come later when more time is available.
This is one of several blockers on the path to getting #19603 merged.
The next step in that chronology will be rebasing that work on top of
this work, which *should* be, on the containerization side, as
straightforward as bumping `Containerfile.base` to reference the new
upstream image, rebuilding the base container, and then bumping the
reference in `Containerfile`.
e4d33b316c