The instructions have, for quite some time now, pointed users at the
`discourse-setup` script. That will prompt the user to create a swapfile
if necessary and configure relevant sysctls.
while `DISCOURSE_MAIL_ENDPOINT` is still accepted by the mail-receiver code, the documentation prefers `DISCOURSE_BASE_URL` and so should this example
see deae52039f/README.md
The new templates/postgres.15.template.yml file allows bootstrapping
new containers using PostgreSQL version 15, or upgrading an existing
container running on older PostgreSQL versions.
The default postgres template and base image shall be bumped in a
follow-up commit.
On a M3 Max macbook pro with 14 cores,
Before:
```
=> [25/44] RUN /tmp/install-imagemagick 150.6s
=> [27/44] RUN /tmp/install-jemalloc 54.9s
=> [31/44] RUN /tmp/install-redis 42.9s
```
After:
```
=> [25/44] RUN /tmp/install-imagemagick 44.4s
=> [27/44] RUN /tmp/install-jemalloc 13.7s
=> [31/44] RUN /tmp/install-redis 11.7s
```
Why this change?
We have noticed that our compiled imagemagick binary is slower than the
distributed binaries in the same environment and started debugging why.
One thing I noticed is that distributed binaries usually include the
`-O2` gcc compilation flag. When applying it locally, I saw significant
speed up.
Without -O2 flag:
```
root@1d7277f72a4f:/# time convert -limit memory 10GiB -limit disk 10GiB -size $(seq 8000 8500 | shuf | head -n1)x9000 xc:"rgb($(shuf -i 0-255 -n1),$(shuf -i 0-255 -n1),$(shuf -i 0-255 -n1))" random_image.png
real 0m3.376s
user 0m6.355s
sys 0m0.410s
root@1d7277f72a4f:/# time identify -format "%Q" random_image.png
92
real 0m1.018s
user 0m0.883s
sys 0m0.135s
```
With -O2 flag:
```
root@0779afa71102:/# time convert -limit memory 10GiB -limit disk 10GiB -size $(seq 8000 8500 | shuf | head -n1)x9000 xc:"rgb($(shuf -i 0-255 -n1),$(shuf -i 0-255 -n1),$(shuf -i 0-255 -n1))" random_image.png
real 0m1.118s
user 0m1.555s
sys 0m1.680s
root@0779afa71102:/# time identify -format "%Q" random_image.png
92
real 0m0.330s
user 0m0.197s
sys 0m0.133s
```
This patch adds some new steps to support the aarch64 architecture
on Linux.
An updated version of Rust is needed to compile the `selenium-manager`
binary as it’s not shipped with the `selenium-webdriver` gem yet.
In the same vein, Google doesn’t ship an aarch64 version of Chrome yet,
so it doesn’t make sense to install even Chromium in the image. We have
to rely on Firefox to run the system specs.
Why this change?
In
dec68d780c,
the `plugin:install_all_gems` Rake task was made a noop because the Rake
task itself was flawed and running a Rake task will actually activate
all plugins which installs the required gems in the process. However,
plugins are not automatically activated in the test environment which
this image operates in. As such, we need to set `LOAD_PLUGINS=1` to when
running the `plugin:install_all_gems` Rake task.
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.
