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.
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).
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.
Set the gcc and llvm versions as variables, and use them anywhere we
install a specific version. We then export these as outputs so that any
interested caller can retrieve the installed versions.
Our check for llvm.list also will have prevented us from upgrading llvm
versions. We now check that it contains the exact version we expect.
Replace itchyny/actions-stale with actions/stale v10.1.1, as the
upstream issue (actions/stale#1136) has been resolved.
Remove the workaround comment that referenced the issue.
The notes-push.yml script was silently failing since the previous URL
now 404s, causing notes to remain unupdated since January 18. This new
URL should work for as long as the git-gloss repository exists.
Due to the name used to upload the test-web artificats missing the
'arch' value, a duplicate name could be generated if multiple CI
jobs use clang_plugins set to true causing artifact upload failure.
Currently not possible to use clang_plugins for these at the same time:
Linux, x86_64, Sanitizer, Clang
Linux, arm64, Sanitizer, Clang
As more CI jobs are added, more possibility of a conflict if using
clang_plugins in more situations.
If the name conflicts the following may by reported:
Error: Failed to CreateArtifact: Received non-retryable error:
Failed request: (409)
Conflict: an artifact with this name already exists on the workflow run
The latest CMake version available on Ubuntu 24.04 is 3.28. We require
3.30 or later for our CMake presets. We can get a newer version from
Kitware's PPA.
This adds a new `test-js-bytecode` target which ensures that codegen
changes do not impact emitted bytecode IR, or if it does, it is known
and the tests are updated accordingly.
Similar to the LibWeb tests, the tests are stored in the following
format:
* `Libraries/LibJS/Bytecode/Tests/input`: Input `.js` files
* `Libraries/LibJS/Bytecode/Tests/expected`: Expected `.txt` bytecode
* `Libraries/LibJS/Bytecode/Tests/output`: Emitted `.txt` bytecode
The `output` dir is git-ignored, but stores the output so you can diff
and inspect failed tests more easily.
There is only one test so far, which is a baseline test that should not
change dramatically unless we change the bytecode output format.
It's unclear what the version is supposed to be on this runner, but
work around any ambiguity by installing CMake explicitly. Previously,
the version was less than 3.30, as a CMake preset update requiring at
least 3.30 caused the workflow to fail.
