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 change helps to ensure issue authors include the details needed to
reproduce problems — including repro steps, expected behavior, a reduced
test case, and logs/backtrace.
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 loader supports whatever format libavformat and libavcodec can
handle. Currently only seekable streams are supported, and we still have
some limitations as to the number of channels and sample format.
Plays all non-streaming audio files at:
https://tools.woolyss.com/html5-audio-video-tester/
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.
In theory the clang module map should not have absolute paths for the
headers. Other Swift projects seem to use the -ivfsoverlay feature of
clang to work around this, but it seems difficult to get to work.
