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.
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.
Starting with CMake 3.30 and CMakePresets version 9, the include field
supports interesting macro expansions. We can now define platform
specific presets in separate files and include them in the top-level
CMakePresets.json, while keeping the same preset names across all
platforms. This avoids some preset explosion at the cost of some mostly
empty json files for each unix platform.
The CMake minimum required in the top-level and Lagom CMakeLists.txt
have not been adjusted in this patch, as that would have the effect of
changing the default policy versions and is a bit out of scope.
ENABLE_WINDOWS_CI and the *_CI presets were initially added back when
the AK library and all the AK Test* executables were the only targets
that supported building and running in CI. Since then, almost all the
targets in the codebase are built on Windows besides the following:
- LibLine
- test-262-runner
Since these targets above are not required to actually run or test the
browser on Windows in its current experimental state, fully disabling
them should be fine for now.
ENABLE_WINDOWS_CI was also used to exclude test-web from ctest. This
can be fully disabled on Windows for now until proper runtime support
is added.
The remaining locations were all using ENABLE_WINDOWS_CI as a proxy for
ENABLE_ADDRESS_SANITIZER, so we can just be explicit instead.
The new presets map much more directly to the unix Release, Debug, and
Sanitizer presets which should make setting up ladybird on Windows less
confusing.
We also make the new Windows_Experimental_Release preset the default in
ladybird.py to match Unix.
We discovered the issue with failed deployments was due to an update to
the checkout action that did not interact well with the deploy action.
There is a fix in the deploy action already. See:
1d137fdcc7
However, a tagged release for the deploy action is not yet available,
and pulling the action at a specific commit hash does not work.
For now, let's pin the checkout action at a known-good version. We can
update both actions when the deploy action has a tagged release. In the
meantime, this just removes the token with write-permissions from the
Ladybird checkout.
Our CI commit linter now evaluates commit messages line by line, similar
to `Meta/lint-commit.sh`.
The URL rule was updated to allow any freestanding URL, optionally
prefixed by whitespace.
We already check if CR is present in the first rule, and although it
would be nice to see all errors at once, we expect people to run
`Meta/lint-commit.sh` before pushing as well. This simplifies our
patterns a bit.
If we run js-benchmarks against older builds that did not yet include
the wasm repl, make sure we skip extracting the file and passing the
`--wasm-executable` argument.
Older commits also have older setup code, such as requiring older XCode
versions - which fails on newer macOS systems. Let's always use the
latest custom actions so we can retroactively support these older
builds.
This allows us to run js-benchmarks against older commits and have the
workflow correctly identify the commit used to build the binaries. In
order to actually build commits where the wasm binary was not yet built,
we have to account for missing archives as well.
The upstream workflow `head_sha` contains the wrong hash in case the
workflow was run manually against a provided commit hash. We use the
COMMIT file that cpack adds to the archive to determine the actual
commit hash that was used to build the binaries.
Note that this will only work for builds since the introduction of that
file, so we cannot process benchmarks for older commits, unfortunately.
Currently we default to GITHUB_REF for the checkout of js-benchmarks,
and if we've built up a large backlog of benchmark jobs to run, this can
mean we're running against a severely outdated version of js-benchmarks.
This new behavior allows us to see a failed js-benchmarks job, fix the
bug, and restart the failed job. This is important since we're testing a
specific commit and build from the upstream JS/WASM workflow.
If we ever want to rerun benchmarks for an older commit, e.g. if we
added new benchmarks that we would want historical performance data on,
we need to consider that some benchmarks might fail because of a bug or
missing feature. For manual runs of the upstream build, pass
`--continue-on-failure` so we simply skip these failing benchmarks.
This allows us to manually kick off jobs for the JS/WASM artifacts
build with an explicit reference to build, which is useful if we want to
generate benchmark results for older commits.
Note that this workflow does not actually produce benchmark results -
that's the job of another workflow. The webhook storing the benchmark
results only appends new benchmarks; existing ones will be kept.
Also note that the GitHub checkout action defaults to the default
reference if `inputs.reference_to_build` is not provided, such as in the
case of a push to the master branch.
This reverts commit 8d46a11748.
The updated webhook supports the newer output format of our
js-benchmarks tool, allowing us to store multiple result types per
benchmark and subtest combination.
