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
The most recent build timed out at 30 minutes. Bump timeout temporarily
to get a gauge on how long self-hosted builds take (push to Dockerhub
looks to be slower than Github-hosted runners).
We can use our self-hosted action/runner machines to build the amd64
Docker images, falling back to the Github action/runner machines for the
arm64 builds.
Additionally, simplify the expression for how arm runners are selected.
The cost savings from switching to self-hosted runners dwarfs the
increase in 8core vs 2core arm runners.
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 use this on the main core repository, so it makes sense to use it here as well. It should reduce the overall flakiness of the discourse_docker build.
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`
Bumping Ruby to 3.3.1 to pull in latest performance and memory
improvements made to YJIT. On Discourse hosting services with Ruby 3.3.1
+ YJIT, we saw an
estimate 10-20% improvement in time spent executing Ruby code over Ruby
3.2.3 + YJIT.
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.
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.
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.
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".
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`
Jeff Wong
Alan Guo Xiang Tan
David Taylor
Jarek Radosz
Mwaniki Wairungu
Michael Fitz-Payne
Martin Brennan
Gerhard Schlager
Rafael dos Santos Silva