Why this change?
The `docker tag discourse/base:aarch64-slim localhost:5000/discourse/base:aarch64-slim
` command broked in 0c93b2207d because
there is no `aarch64-slim` image being built. Instead, the `ruby
auto_build.rb base_slime_64` command builds an image with the
`discourse/base:build_slim_arm64` tag.
What does this change do?
This change removes the tagging command because it is pointless for us
to tag it.
Why this change?
In CI, we are seeing the following warning message:
```
WARNING: experimental flag squash is removed with BuildKit. You should squash inside build using a multi-stage Dockerfile for efficiency.
```
Basically, the `--squash` flag has not been working for quite some time
and is redundant.
What does this change do?
* This change removes the use of the `--squash` flag.
* This change uses the `buildx` tool in `auto_build.rb` as we prepare to
build images for multiple platforms.
Why this change?
Previously we were running `gem install bundler` to install bundler but
this would install the latest bundler version instead of the bundler
version being used by Discourse. As a result, we end up having to
install bundler over and over again when using the image most of the
time.
Relies on discourse/discourse#22975 to be merged first;
the minio_runner gem can self-install minio, but it's better to just bake the binaries
into the test image. Just uses the script/install_minio.rb script to use the gem to
install required binaries.
We are adding minio to the core project to run system tests for S3 uploads
using minio as a mock S3 store.
Before, if a remote server is upgraded to a newer PG version, it wouldn't be able to be backed up from inside the application, since `pg_dump` would be a lower version, resulting in this:
```
pg_dump: error: server version: 15.3; pg_dump version: 13.11 (Debian 13.11-1.pgdg110+1)
pg_dump: error: aborting because of server version mismatch
```
With this change, `postgresql-${PG_MAJOR}` pulls in `postgresql-client` for the server version, AND `postgresql-client` metapackage pulls in the latest version available in the upstream Apt repository.
This guarantees there will be a `pg_dump` for the latest version available, so a remote server freshly upgraded to that latest version will always be able to be backed up from inside the application (since [`pg_wrapper`](https://github.com/credativ/postgresql-common/blob/master/pg_wrapper#L110) chooses the latest locally available version for remote connections).
* Bump Postgres client version ahead of Postgres server version bump
* Fall back to PG_MAJOR if client env var is undefined
* Use postgresql-client metapackage instead for latest client version
ripgrep is going to be used by discourse-ai to extract context from files
on the local disk.
This does increase the size of the image by 1.7MB or so, but heavily simplifies
deployment
Alternative mechanisms exists such as packing the binary in a gem but we
would pay more at install time delays.
Unfortunately there is no way to 'unset' an ENV in a Dockerfile. We were working around this by setting `RAILS_ENV` to an empty string in the discourse_dev dockerfile, but that didn't work in every situation.
The discourse_dev image doesn't rely on anything in the 'release' layer of the base image. In fact, it deletes the entire contents of `/var/www/*`.
This commit resolves the situation by:
- Moving the `RAILS_ENV=production` line to the 'release' layer of the base image
- Updating the discourse_dev image to be based on the 'slim' base image
Yarn seems to have issues 'downgrading' our set of packages from tests-passed (which are pre-installed in the base image) to the versions on the stable branch.
In the medium term we intend to switch to the pnpm package manager, which shouldn't have this issue. In the meantime, we can work around the problem by deleting the pre-installed node_modules and installing from scratch.
https://meta.discourse.org/t/270491
This tooling adds significant size to our docker image. We only need rust tooling while installing ruby/oxipng, and can clean it up immediately afterwards to avoid it persisting in the image
Fetching the maxmind database requires a license key, which we do not include during our base image build. This rake task has been failing with an error for some time
```
MaxMind IP database updates require a license
```
Following 0330f51d75, the task now hard-fails and breaks the build.
`devDependencies` is often used for things like ember-cli build tooling. Until now we have been moving those things to `dependencies` in our `package.json`, but it makes more sense for us to conform to the industry norms.
Over the years we had LOTS of cases of PostgreSQL instances that weren't stopped properly. This gives PG more time to handle it's shutdown cleanly on the worst case, but will still shutdown fast in normal cases.
This is particularly useful when the version is pointing to a git tag like `beta`, otherwise we won't be able to reliably detect the tracked version at runtime.
We are replacing the `beta` branch with a tag of the same name. Rebuilding a container will fail when a user tracks the `beta` version and the base image was built at a time where `beta` was still a branch. This resolves that by pruning tags and branches and forcing an update of tags during the rebuild.
Ruby 3.2.2 was released with a two security fixes. While the security
fixes have been assessed to have low impact on Discourse, we still want
to get the upgrade in as a preventive measure.
By default nginx in the container only listens for IPv4 connections. Some users
want to enable direct IPv6 connectivity to the container either via forwarding
or NAT. This provides an easy method to allow that.
Check for Ubuntu 22.04 and 22.10 versions before trying to use
`bullseye-backports` otherwise they throw this error.
```
E: The value 'bullseye-backports' is invalid for APT::Default-Release as
such a release is not available in the sources failed
```
A treeless clone is nearly as small as a shallow clone, but it contains the full history which makes it possible to easily checkout tags and commits and allows all features of docker_manager to work correctly.
See https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ for more information on treeless clones.
Also this change makes it possible to correctly pull the main branch which didn't work before.
This uses the new sparse-registry feature from Rust 1.68 which lowers the memory usage. This avoids that cargo is killed due to an OOM issue (exit code 137) during "Updating crates.io index".