Bump the workflow image pin to the 2026.06.14 tag that bakes in
wasm-tools. And keep the wasm-tools download/caching steps for the macOS
and Windows jobs — but skip those steps on Linux. So, the Linux jobs use
the wasm-tools copy the image installs.
Follow-up to https://github.com/LadybirdBrowser/ladybird/pull/9972
Otherwise, without this change, the Lint Code job intermittently fails —
for the same cause described in 61d0fca133: rustup tries to auto-install
1.96.0 the first time a proxied cargo runs — and depending on timing,
that can lead to a crate ending up seeing rustc, but not cargo.
The Linux CI workflows were still pinned to ladybird-ci:2026.05.4, even
though the CI image had since been rebuilt as 2026.05.25 after the Rust
toolchain switched to nightly.
This left CI running in an older container where cargo was not installed
for the nightly toolchain selected by the checked-out tree, causing Rust
crate builds to fail during the fuzzer host-tools build.
Update the workflow image references to the current published CI image.
This means running the build inside a Docker container based on a (more)
stable build image.
* The setup action is now largely simplified for Linux.
* We hardcode llvm@21 for macOS since it allows us to get rid of
specifying llvm_version as an input variable. Since we no longer
support switching the LLVM version on Linux via that variable, this
seems like the best course of action.
We use a trick to optionally introduce a container image: `fromJSON()`
allows `null` as a return value, which causes the job to execute on the
runner directly. We need this for macOS and Windows jobs.
We switched to macOS since it was easier to install swift-format in CI.
With that removed, let's switch back to Linux, as macOS runners tend to
have higher contention.
To do so, this makes more use of the setup action. This way, the setup
action is the only place that needs to know how to install the apt repos
we need (LLVM in particular).
We could use flake8 for linting, but ruff is compatible with black
formatting out-of-the-box. It also seems to catch more than flake8,
such as unnecessary f-strings.
This reverts commits bf333eaea2 and
6f69a445bd.
The commit linter needs to run on event `pull_request_target` to have
access to its secret token, which means we cannot have a dependency on
that job from another workflow that is run as a result of the
`pull_request` event.
Additionally, the linters were no longer run for first-time
contributors. This isn't a huge problem but it was nice that a
preliminary check took place before running the full CI on their PRs.
We can prevent running builds unnecessarily by requiring the linters to
succeed first. If either the code or commit linter fails, it means the
author of the PR needs to rework their branch and after pushing their
changes, we need to do a full new CI run anyway.
swift-format is only packaged for homebrew, Arch, and nixpkgs at the
moment. Rather than installing swiftly and a swift toolchain, let's
change the job to run on macOS.
Unlike in Serenity, let's just run this job once per PR rather than on
every job. This lets us install fewer dependencies on the build-and-test
pipelines.
