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.
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.
Apart from the fact that this workflow is failing every time, we don't
need to check the branch we're on since it's only invoked for the
default branch of the repository. We can also remove the `always()`
since there are no job dependencies nor do we want this to be
uncancelable.
Matching `master` can be a bit simpler and prevent invoking the job
altogether. Additionally, we don't need an `always()` here: we don't
have job dependencies and we want these jobs to be cancelable.
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.
This action adds and removes the new "conflicts" label to indicate
whether a pull request is in need of conflict resolution. This both
automatically informs the author of the PR that this is the case, if
they have notifications enabled that is, and makes for an easier
evaluation of the PR queue.
The stale action has a weird interaction with the cache which requires
the `actions: write` permission. Without this, it is unable to overwrite
any existing cache key.
We want to remind both contributors and maintainers that PRs should be
up-to-date, reviewed and merged. Stale bot does a pretty good job of
notifying the right people :^)
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.
Merely specifying `self-hosted` is not enough - to get closer to
reproducible timings, we want these jobs to run on dedicated hardware.
The `test262-runner` label was introduced for runners that offer this.
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.
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.
