The idea is that scripts directly under Meta are meant to be run by
people. Scripts that are only imported or run by other scripts are
moved to a subdirectory.
Note that the IPC lint step can be removed from the CI workflow because
we no longer need a build in order to perform the lint, and IPC linting
is now covered by lint-ci.sh.
The vcpkg cache should rarely change - only when new dependencies are
added or a version changes. Both of these events involve modifying the
vcpkg.json file. So instead of uploading duplicated vcpkg caches in each
workflow, let's only upload changed caches.
It doesn't make a whole lot of sense leaving out this variable. We use
the toolchain to construct the main cache key for our ccache and vcpkg
caches, and the JS+WASM artifacts build defaulted to 'GNU' for their
toolchain which got really confusing.
These were originally introduced to make it possible to discern between
GitHub's and Blacksmith's caches. This is no longer necessary since
Blacksmith resolved some issues _and_ switched to transparently
proxying GitHub cache actions to their own caches.
This allows us to get rid of the annoying Build/.../Lagom directory
and helps to deduplicate a bunch of logic while also drastically
simplifying everything.
This is largely based of off the work done by Andrew Kaster in #5918.
Having this toggle makes much more sense, especially if there will be
more UIs in the future.
Co-authored-by: Andrew Kaster <andrew@ladybird.org>
This is entirely a GitHub limitation. But I have found myself wanting to
rerun flaky CI tests, but have to wait some time for the flatpak builder
to complete. Moving this to its own job means we don't need to wait to
restart other CI jobs.
In 1d03944a9c failures from pushing notes were ignored entirely due to
the command failing sporadically. Looking at the original commit message
this was almost certainly due to the fact that multiple runs of the
workflow could happend simulaneously if PRs were merged in quick
succession:
1. PR 1 gets merged.
2. Workflow run 1 gets triggered for newly pushed `master` commit from
PR 1 and fetches notes ref at `aaaaaaa`.
3. PR 2 gets merged.
4. Workflow run 2 gets triggered for newly pushed `master` commit from
PR 2 and fetches notes ref at `aaaaaaa` as well.
5. Workflow run 1 finishes its work and pushes `bbbbbbb` to the notes
ref.
6. Workflow run 2 finishes as well, tries to push `ccccccc` to the notes
ref, but gets rejected. This is because its changes are based on
`aaaaaaa` and cannot be fast-forwarded due to workflow run 1 having
pushed different notes in the meantime.
This sequence of events could also be observed after bbad346add got
merged, which caused the first couple workflow runs after to be very
slow as they were processing a large backlog of missing notes.
Instead of silencing the error when it happens and relying on the fact
that the next run will correct it, let's just prevent the conflict from
happening in the first place by disallowing parallel runs of the
workflow. This avoids unnecessary workflow runs and allows detection of
other, unexpected errors happening when pushing.
bbad346add corrected a URL that broke several weeks ago. This problem
went unnoticed for a while partially because the workflow runs were all
still passing. A failure of a command in an &&-list is only considered
an error if it occurred in the last command of the list, even with `set
-e` being active (set automatically in GitHub actions).
From the Bash Reference Manual, 4.3.1 The Set Builtin:
> The shell does not exit if the command that fails is [...] part of any
> command executed in a && or || list except the command following the
> final && or ||.
Let's make download failures easier to disover by failing the workflow.
Every master-push getting marked with a red x-sign would probably have
been caught earlier.
We switched to macOS since it was easier to install swift-format in CI.
With that removed, let's switch back to Linux, as macOS runners tend to
have higher contention.
To do so, this makes more use of the setup action. This way, the setup
action is the only place that needs to know how to install the apt repos
we need (LLVM in particular).
The Rust-based LibJS codegen is now enabled by default on non-Windows
platforms, so CI runners need rustc and cargo available. Add the
dtolnay/rust-toolchain action to install a stable Rust toolchain.
On GitHub runners (which are much slower than blacksmith runners),
test262 only takes ~6 minutes nowadays. So let's try running it on
blacksmith. It's generally been a headache to make changes to the
test262 workflow on our dedicated runner, so this will alleviate
that.
