Starting with CMake 3.30 and CMakePresets version 9, the include field
supports interesting macro expansions. We can now define platform
specific presets in separate files and include them in the top-level
CMakePresets.json, while keeping the same preset names across all
platforms. This avoids some preset explosion at the cost of some mostly
empty json files for each unix platform.
The CMake minimum required in the top-level and Lagom CMakeLists.txt
have not been adjusted in this patch, as that would have the effect of
changing the default policy versions and is a bit out of scope.
ENABLE_WINDOWS_CI and the *_CI presets were initially added back when
the AK library and all the AK Test* executables were the only targets
that supported building and running in CI. Since then, almost all the
targets in the codebase are built on Windows besides the following:
- LibLine
- test-262-runner
Since these targets above are not required to actually run or test the
browser on Windows in its current experimental state, fully disabling
them should be fine for now.
ENABLE_WINDOWS_CI was also used to exclude test-web from ctest. This
can be fully disabled on Windows for now until proper runtime support
is added.
The remaining locations were all using ENABLE_WINDOWS_CI as a proxy for
ENABLE_ADDRESS_SANITIZER, so we can just be explicit instead.
The new presets map much more directly to the unix Release, Debug, and
Sanitizer presets which should make setting up ladybird on Windows less
confusing.
We also make the new Windows_Experimental_Release preset the default in
ladybird.py to match Unix.
These existed because of their `vcpkg_ci` base preset, whose goal was to
enable vcpkg-supported caching on GitHub. We now handle vcpkg caching in
the CI steps, removing the necessity for all these *_CI preset variants.
This allows us to reuse `inputs.build_preset` in the test step, and we
can do away with the Windows-specific test step since it is now almost
identical to the Linux/macOS test step.
I've left in the Windows_CI presets, because that one actually results
in a different set of compiled files compared to the
Windows_Experimental presets.
Having the pull_request 'labeled' event trigger the main CI is much too
impactful, since it cancels running jobs and does not start anything if
the label is anything else than 'windows'. Let's go with a different
approach and put the Windows CI job in a separate workflow.
How this works:
* Jobs are only run if the 'windows' label is present on the PR.
* If a PR is opened or updated, existing jobs are canceled.
* If a PR is (un)labeled, existing jobs are only canceled if the label
was 'windows'. Other labels cause the job to be rescheduled.
As far as I can see, there's no way to prevent the job from being
rescheduled when labels other than 'windows' are being added or removed.
However, by not canceling the existing Windows job, we can try to create
a cache so the next run will be much quicker.
Each matrix item now defines whether it is enabled, and if not, the job
conditionally disables itself. Apparantly we cannot use expressions in
`matrix.exclude`, but it should work in the items' definitions.
This has the added benefit that this makes the job show up as "skipped",
which could serve as a hint that it could be run on a PR.
Our CI matrix now includes Windows if the 'windows' label is added to
the PR. The job still takes too long to include it for every PR, but it
is certainly useful to have it run on Windows-specific PRs and PRs that
might break Windows builds.
By default, matrix jobs generate a name for themselves by concatenating
their job name and all matrix variables into a big string. Changing the
runner labels causes the job name to change, which means we need to go
into GitHub and change the required checks since those are name-based.
Give all matrix workflows an explicit, more stable name.
The GitHub-provided runner frequently times out and is plain slow most
of the time. And since Blacksmith does not yet offer macOS runners,
let's use our self-hosted runner that is currently idle most of the time
(when it's not running JS benchmarks).
This is now always a JSON array of runner labels, inside a string. We
need it to be a string because `workflow_call` works with inputs that
do not natively support an array type.
No functional changes.
Everything that's not self-hosted or macOS is now pointing to
Blacksmith.sh. Nightly jobs and JS artifact builds use 8VCPU machines,
while regular integration builds & tests use 16VCPU machines.
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.
This requires us to always run the CI job and check the individual jobs'
results, since only having `needs:` will not work when `lint_commits` is
potentially skipped.
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.
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.
Originally we used the `paths-ignore` feature to skip the Lagom jobs if
no source code was changed. Afterwards, we enabled the 'required checks'
feature to prevent merging pull requests that have failing checks.
Unfortunately, marking a check as required means it always needs to be
successfully executed, even if a conditional caused it to be skipped.
By using the `paths-filter` action we were able to add the conditional
to the job instead, theoretically causing the 'required checks' feature
to start working again for documentation-only changes. As it turns out,
not the job, but the steps should get the new conditionals.
As that requires adding an `if` to every individual step and the
conditional execution has caused enough headaches since its
introduction, let's remove it for now and take the unfortunate execution
of CI jobs for granted.
We need to invoke the CI jobs every time, even if nothing relevant has
changed, because we marked them as required status checks for PRs. If
they are not invoked, the associated status checks remain in a 'pending'
state indefinitely not allowing us to (auto-)merge the PR.
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.
