web_only images do not install postgres or redis, minimizing image sizes for
setups that do not require those components.
release and dev images still install postgres and redis, but do it later in the
process.
remove rm runs
rm no longer affects image sizes as we are no longer squashing images
This commit updates the build workflow to build and push an extra base Docker
image with PG 15 installed. The tag is not meant to be permanent and is
just meant to help us update our postgres templates to support PG 15
within the same commit.
The tag will be removed once our `discourse/base:release` ships with PG
15 by default.
This commit updates our `build` workflow to push the following manifests
which can be used to run Discourse against the stable branch.
1. discourse/base:2.0.$TIMESTAMP-stable
2. discourse/base:release-stable
Co-authored-by: David Taylor <david@taylorhq.com>
- Combines dev image build into the `base` job
- Calculates a single timestamp for all builds
- Pushes timestamped per-arch images to Dockerhub for base, base-slim and dev images
- If both arch build jobs are successful, multiarch manifests are generated & pushed
We need to upgrade to bookworm because bullseye is EOL. This commit when merged into branch will push the following images to Docker hub:
1. `discourse/base:slim-bookworm`
2. `discourse/base:release-bookworm`
3. `discourse/discourse_test:slim-bookworm`
4. `discourse/discourse_test:slim-browsers-bookworm`
5. `discourse/discourse_test:release-bookworm`
This commit adds a `ruby_3_3` job to our Github workflow which releases
a `discourse/base:release-ruby-3.3.1` Docker image to allow us to test
Ruby 3.3.1 before eventually changing to that version as the default.
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?
We have been given access to Github's private beta of ARM hosted
runners. Switching to ARM runners should drastically speed up the time
required for us to build our ARM image.
What does this change do?
1. Switch to use Github's ARM hosted runners.
2. Build release image for arm64 as well. We previously only built the
slim image because building the release image through emulation is
way too slow so we skipped the release image.
3. Update `bundle` in `release.Dockerfile` to install gems in parallel
based on the number of cores instead of hardcoding it to 4 jobs.
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 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.
Per the docs, first parameter for the block is STDOUT + STDERR, 2nd one is STDIN:
https://ruby-doc.org/3.1.3/exts/pty/PTY.html#method-c-spawn
As it is now, the method looks like it's reading from STDIN, though in
fact it's reading from an incorrectly named parameter for STDOUT.
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`
- Only attempt dockerhub push if previous steps are successful
- Make auto_build.rb exit with non-zero status if build fails
- enable experimental features (--squash) for dev image build
Jeff Wong
Alan Guo Xiang Tan
David Taylor
Loïc Guitaut
Leonardo Mosquera
Jarek Radosz
Rafael dos Santos Silva
Guo Xiang Tan