We started installing Chromium because there is no linux ARM support
for Chrome yet. However, trying to run tests on Chromium seems to be
extra challenging. For example, upgrading to Debian 12 causes our
Javascript tests to fail on Chromium but not on Chrome.
Chrome for Testing was built specifically for web app testing so let's
follow Google's recommendation.
This fixes a regression introduced in
bbefa1e5f3. Basically, we cannot configure
the default bundle jobs when building the image because the number of
cores used to build the image can be different from the number of cores
on the machine running the image.
Chrome isn’t available for aarch64 yet, but Chromium (which is basically
the same browser without the proprietary bits from Google) is shipped by
Debian. They also ship a Chrome driver compiled for aarch64.
This patch adds Chromium to our images without removing Chrome on
x86_64, allowing a smooth transition to using Chromium only.
Chrome isn’t available yet for aarch64, but Chromium (which is basically
the same browser without the proprietary bits from Google) is shipped by
Debian. They also ship a Chrome driver compiled for aarch64.
By using Chromium instead of Chrome, we unify how we do things
regardless of the architecture used in the generated image.
Why this change?
Now that we can efficiently build Docker images targeted at `linux/arm64`,
we will start to release images for `linux/arm64` in the same way we do
for `linux/amd64` images.
Images released for `linux/amd64` are tagged as follows:
1. discourse/base:2.0.\<datetime\>-slim
2. discourse/base:slim
3. discourse/base:2.0.\<datetime\>
4. discourse/base:release
For `linux/arm64`, the images are tagged as follows:
1. discourse/base:2.0.\<datetime\>-slim-arm64
2. discourse/base:slim-arm64
3. discourse/base:2.0.\<datetime\>-arm64
4. discourse/base:release-arm64
5. discourse/base:aarch64 (For backwards compatibility)
For `linux/arm64`, we unfortunately cannot install chrome because chrome
does not currently release binaries for the arch. Therefore, we install
chromium which chrome is based off and also install the chromedriver
binary for `linux/arm64` released by the electron project.
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.
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.
The slim images aren't able to run the full `rake docker:test` task, so having it as the entrypoint doesn't make sense. We only want it as the entrypoint on `discourse_test:release`
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.
* Ruby 2.6.3 which has a couple of Unicode improvements
* nginx from 1.5.9 to 1.5.12 (http://nginx.org/en/CHANGES)
* ImageMagick 7.0.8-42 and switch it back to using GitHub, because only the latest release is available on the official site and this regularly breaks our build
* libpng from 1.6.36 to 1.6.37 (security fix)
* gifsicle from 1.91 to 1.92 (http://www.lcdf.org/gifsicle/changes.html)
* Node.js v10, the latest active LTS (https://nodejs.org/en/about/releases/)
This fixes the following error during image build:
sane@4.0.2: The engine "node" is incompatible with this module. Expected version "6.* || 8.* || >= 10.*". Got "9.11.2"
Move "discourse" user and "/var/www" directory creation into base image
so that discourse_dev can build from base image directly instead of
requiring the overhead of the full discourse image.
Remove discourse_fast_switch dependency from discourse_dev, and remove
the ruby 2.2/2.0 logic, as Discourse already appears to require 2.3.0 or
greater.
Remove discourse_dev's independent `postgres.template.yml` and
`redis.template.yml` files, and instead derive them from the top-level
templates directory. This ensures that the discourse_dev image is
always up-to-date with the discourse main image.
Add password-less "sudo" permissions for the "discourse" user in the
discourse_dev image. This simplifies (fixes) the "bundle install"
command (and others) as implemented by discourse/bin/docker utilities.
Add image/Makefile so that images can be built even on machines without
Ruby installed. Logic is replicated from `image/build.rb`, and should
result in equivalent images. (Perhaps build.rb should be removed?)
Add automation in Makefile to ensure that all Dockerfiles are updated to
match the version number in the Makefile. (This includes the `/VERSION`
file written into the base image.)
Add image/README.md to describe the images and process.
Update ImageMagick to 6.9.5-9 in the base Dockerfile because 6.9.5-8 is
no longer available. (Perhaps this dependency should be vendored.)
Fix base "boot" failure caused by missing log files on a new instance
(in `base/runit-1.d-00-fix-var-logs`). Before chowning the log files,
"touch" them to ensure they exist. This failure previously prevented
the discourse_dev `ensure-database` script from running, which made
development use of discourse_dev very difficult.
Update to version 1.3.7. (Driven by IMAGE_VERSION in the Makefile.
Mostly, this is to ensure that the next official build of the images
will be *at least* 1.3.7, superseding any previous versions.)