This was a relic from the SerenityOS CI, where architecture meant
what architecture to build Serenity for. For just ladybird, we might
want to build ladybird for multiple architectures per OS.
Becuase we're using dynamic libraries, our configuration is
classified as a "community triplet". To not confuse vcpkg
maintainers when developers create bug reports, name them
properly. This means that the default triplet detection is now
kind of useless, so we have to invent our own for these triplets.
Even in a successful LibWeb test run, on Linux, we currently always have
LSAN output. Causing this step to fail is currently making every run of
CI fail.
If LibWeb tests did fail, they should exit with a non-zero status code
on their own, causing the pipeline to fail.
Instead of writing ASAN and UBSAN output into the same stream we use for
test logging, direct them to log files, named asan.log.$PID and
ubsan.log.$PID, and then output them in a separate CI job that runs
afterwards. This should hopefully make it easier to see which tests are
failing.
The downside is that it's now harder to tell which tests the *SAN errors
are related to.
From this action's documentation, "0 means using default retention."
There's no reason for this to have a different retention duration than
the CI results themselves.
Without this, if two CI runs on Linux both fail and want to upload
screenshots, we get an error like this on the second:
> Error: Failed to CreateArtifact: Received non-retryable error: Failed
> request: (409) Conflict: an artifact with this name already exists on
> the workflow run
Using all the inputs as part of the name should make this kind of
conflict impossible.
Our GCC pipeline is regularly timing out. When it doesn't time out, it
finishes just under the default 25 minute limit. Let's bump the timeout
to 30 minutes to give it a bit more wiggle room.
This reverts commit aeaa284be3.
This didn't actually help. It appears we actually just get stuck, so
increasing the timeout to an hour just makes CI take longer.
We seem to be brushing up against the 1500s limit (25 minutes) on both
macOS and Linux+GCC workflows. As we keep importing more WPT tests, we
will exasperate the issue.
For some reason, Microsoft have decided to remove Xcode 16 from macOS 14
images. We require Xcode 16 for Swift 6.
See: https://github.com/actions/runner-images/issues/10703
Because macOS 15 images are still in preview, their availability is much
lower than macOS 14 images. To hopefully alleviate the amount of time we
are waiting in the runner queue, for now this only upgrades the workflow
which uses Swift.
In addition to changing the build-type dependent build directories, we
can take this opportunity to move the vcpkg cache directory to the Build
folder itself. This probably isn't 100% needed, but it ensures that no
leftover artifacts are used from non-dynamic vcpkg builds, and it's also
generally nice to have all build artifacts under Build.
This uses the setup-python action in the setup action to install python
3.12, and removes the --break-system-packages hack that the system pip
requires.
This is needed to allow using clang plugins during PR workflows. They
currently are not included because they resulted in a clean build on
each run. With this, they should be cached.
The plugins build that runs on master currently uses the same ccache key
as non-plugin builds in PRs. This means all clang PR builds are not able
to use ccache.
Move the plugins build to a separate job. This job also has sanitizers
disabled to make the plugins build quicker.
AK will depend on some vcpkg dependencies, so the Lagom tools build will
need to know how to use vcpkg. We can do this by sym-linking vcpkg.json
to Meta/Lagom (as vcpkg.json has to be in the CMake source directory).
We also need a CMakePresets.json in the source directory, which can just
include the root file. The root CMakePresets then needs to define paths
relative to ${fileDir} rather than ${sourceDir}.
Most users will be building with Xcode Clang on macOS anyway, as our
build scripts default to the system compiler if it's new enough. We
already have an upstream Clang-based workflow on Linux, so we won't lose
any compiler coverage by switching to Apple Clang on macOS.
This should help us avoid build breakages like #186.
This changes the Sanitizer configs to build all the vcpkg dependencies
with our specified CFLAGS and CXXFLAGS for ASAN and UBSAN.
Unfortunately, we can't yet enable actually compiling them with
sanitizers enabled, because this causes test failures that need to be
investigated.
And hook it into ladybird.sh for convenience. The script will set up
PATH and other environment variables automatically.
On CI, vcpkg is theoretically already installed on Linux machines, but
not with the right environment variables, and not on macOS. So this also
makes CI use this script to bootstrap vcpkg.
