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.
It’s possible but unlikely that a push of generated notes back to the
remote can fail with a message like
> [remote rejected] ... cannot > lock ref 'refs/notes/commits': is at
> f3648f50bb but expected 47686bf473
See https://github.com/LadybirdBrowser/ladybird/actions/runs/10054314539
So this change makes the call to “git push” for notes not return 0 even
if it fails — because it’s not actually a fatal error when it happens,
and not something we need to stop and fix. Instead, it fixes itself.
Specifically: If one CI job for a PR merge/push to master generates
some notes but fails to push them to the origin, the notes don’t get
dropped on the floor and lost.
Instead, the notes-generator tool looks at the entire history; and if it
finds commits that don’t have notes — even if those commits are not part
of the PR push/merge it’s operating on — it generates notes for those.
In other words, if notes for one PR push/job fail for some reason to get
pushed back to the remote, they get regenerated by the next PR push/job.
libqt6svg6-dev - We don't use Qt's SVG support any longer.
qt6-multimedia-dev - We already install libpulse-dev, so the Qt6
multimedia package is unused.
This change makes the notes-push.yml·workflow fetch the entire history
on each push, rather than just the one HEAD commit it otherwise sees.
Because we push multiple commits from PR merges, git-gloss need access
on each push to an arbitrary number of commits (however many commits
were pushed in a PR that got merged). There’s no easy way from GH
Actions to know how may commits got pushed at the same time. So we
instead fetch the whole history.
This change, for each commit pushed/merged to master:
- causes new git Notes with GitHub PR/issue/reviewer/author links to be
auto-generated for that commit
- pushes the updated refs/notes/commits tree+references back to the repo
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}.
Trying to build VulkanLoader from source is a giant headache of
unnecessary packages. Every modern distro has vulkan packages, let's
depend on those instead of trying to build something for both wayland
and X11.
