* Upgrade to Node 18
* Run audit fix to resolve node 16 openssl issue
* Update babel.config.js
* Replace node-version with node-version-file
* Add NODE_OPTIONS
* Specify major version only
* Try setting locally instead
* Try custom hashFunction
* Trying two things at once
* Try without legacy option
* Add back openssl-legacy-provider
* Add resolution for terser-webpack-plugin
* Use older terser-webpack-plugin
* Revert changes to CI
* Add compression-webpack-plugin to resolution
* Use new node_module cache
* Add NODE_OPTION in build_test
* Maybe remove redundant label
* Upgrade storybook
* Update bin/webpack
* Revert "Upgrade storybook"
This reverts commit fca3fb5c8718786b7db20538c5c4ae6cf44b45b8.
* Remove unnecessary change
* Update yarn.lock again
* Now try with Node 20
* Upgrade Node module cache CI
* Lint
* Update base image sha
* Update ruby to v3.2.0
And ruby-next to v3.2.1
* Update .ruby-version-next
---------
Co-authored-by: Mac Siri <mac@forem.com>
Co-authored-by: Mac Siri <krairit.siri@gmail.com>
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`.
