I came here to do something else, but could not help cleaning up the bootstrap
code.
* add die() helper
* pull the container ID into an environment variable right away instead of
interpolating it every time
* we don't need to write out to a file prior to piping it into docker
* use $() instead of backticks
* tidied up messaging from failed docker commits
After several months of using btrfs in our forum in production with no issue, I can say that btrfs seems quite stable and I am proposing to add it to the supported storage drivers under docker.
Using btrfs makes it a breeze to take snapshots and revert to a previous state of discourse, and taking backups with minimal forum interrupt time.
Here is a discussion about it in discourse forum:
https://meta.discourse.org/t/unable-to-rebuild-app-not-supported-docker-storage-driver-btrfs/209200/14
Bundler 2.3.0 started re-installing and re-invoking itself based on the `BUNDLED WITH` declaration in the Gemfile.lock. The second run of bundler doesn't receive the flags from the initial invocation.
These flags were deprecated some time ago. The recommended solution is to use `bundle config`, which persists the config to the filesystem for future invocations to load.
There has likely been one s/12/13/ too many in this file.
Note: the typo is not present in the default postgres template; only this specific file, which is otherwise identical to the default one.
The base-slim image doesn't run `yarn install` or `bundle install`, so it is much more lightweight. This is intended for use by systems which do their own dependency caching (e.g. GitHub Actions)
The image will be released under the `:slim` tag, and also `:v2.0.{timestamp}-slim`
By doing `rm -rf .bundle` and `bundle install --standalone`, we were setting up bundle to install gems in `./bundle`. The base file installs gems in `./vendor/bundle`. That means that the test image was ending up with two complete copies of our dependencies.
This commit removes the `--standalone` command, and allows the `./vendor/bundle` artifacts to be re-used in the test image.
A buffer overflow vulnerability (CVE-2021-3973) has been discovered in
vim. As of the moment, this remains unpatched in Debian. Admittedly the
likelihood of encountering this exploit in the wild within the Discourse
base image is pretty low, but given this image is intended to run
non-interactively vim is not strictly required as a part of the image.
In any case, the package can be added at runtime for debugging purposes.
See https://security-tracker.debian.org/tracker/CVE-2021-3973.
The old root was getting openssl confused, resulting in a new
certificate on every rebuild that could easily trigger existing let's
encrypt rate-limits.
Recent changes to let's encrypt having to do with the surprisingly tragic root certificate update are causing sites not to have `force_https` set.
This set force_https.
There remain some issues with let's encrypt requesting certs when it shouldn't but this fixes the worst of the problem with little effort.
The cache is not required to run the application. This should make the docker image much smaller.
We may want to re-evaluate this decision when switching to yarn v2, which has a very different caching system.