This change adds and alternate method for triggering try changes.
Instead of comments, changes are triggered via applying labels to pull
requests. The action will remove the label from the request and start
the requested jobs.
This will require creating at least a few labels:
- T-full
- T-linux-wpt-2013
- T-linux-wpt-2020
- T-macos
- T-windows
More labels can be added as we support more configurations.
The good thing about this change is that try jobs against the actual
branch in the pull request instead of the master branch. This means
that changes to CI can be tested (unlike for comment processing).
One bit caveat with this change is that when adding multiple labels, a
CI job is triggered for each. Only one real build will run for each
label, but whether or more try jobs is triggered is a race condition.
The first CI job to successfully remove the label will actually trigger
the job. If the same job removes two compatible labels, then they can
share a build (for instance two types of WPT linux jobs). If not there
will be two. Note that this is at least as efficient as the current
behavior.
This logic was more important when bors was triggering duplicate
workflows. Now that we've switched away from bors, benefit is much more
marginal. In addition, it adds a bunch of complexity to an already
complicated workflow. We can always re-add it later if we notice too
many duplicated workflows.
The default GITHUB_TOKEN is created for 'github-bot' user and has limitations.
Specifically, events generated by this github-bot
cannot trigger additional workflows.
This PR uses fine-grained PAT generated for @servo-bot account with the
permissions scoped to servo/servo repo and grants the
'contents: write' and 'pull_request: write' permissions.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
LLVM is the largest package that we get from servo-build-deps, so
installing it via chocolatey should reduce the amount of data that we
transfer from that source. In addition, it's one less dependency that we
have to manage.
It also seems that installing LLVM to the default location with choco
means that we no longer have to set the LIBCLANG_PATH environment
variable for bindgen.
Co-authored-by: Mukilan Thiyagarajan <mukilan@igalia.com>
* Allow noidl files in script/dom/webidls
* Upgrade wgpu to 0.16 and refresh whole webgpu implementation
* Update WebGPU test expectations
* misc
* MutNullableDom -> DomRefCell<Option<Dom for GPUTexture
* Direct use of GPUTextureDescriptor
* Remove config from GPUCanvasContext
* misc
* finally blue color
* gpubuffer "handle" error
* GPU object have non-null label
* gpu limits and info
* use buffer_size
* fix warnings
* Cleanup
* device destroy
* fallback adapter
* mach update-webgpu write webgpu commit hash in file
* Mising deps in CI for webgpu tests
* Updated expectations
* Fixups
* early reject
* DomRefCell<Option<Dom -> MutNullableDom for GPUTexture
There are currently two ways to run try. One is to push to the `try` or
`try-*` branches and the other is to trigger a workflow via GitHub
comment. This change combines these methods into one workflow. In
addition, WPT results are reported together rather than separately and
filtered results for all WPT tests are bundled together in the same
artifact.
There were some issues with the way that the `--release` and `--dev`
arguments were handled in mach commands.
- Not all commands accepted them in the same way. For instance `./mach
test-wpt` didn't really accept them at all.
- If you did not pass either of them, mach would try to guess which
build you meant. This guess was often quite surprising as it wasn't
printed and it depended on the state of the your target directory,
which is difficult to remember.
- The `dev` profile is colloquially called a "debug" profile and some
commands accepted `-d` or `--debug...` like arguments, but `--debug`
with `./mach run` meant run in a debugger. It was easy to mix this
up.
This change:
- Centralizes where build type argument processing happens. Now it the
same shared decorator in CommandBase.
- Uses a `BuildType` enum instead of passing around two different
booleans. This reduces the error checking for situations where both
are true.
- Be much less clever about guessing what build to use. Now if you
don't specify a build type, `--dev` is chosen. I think this behavior
matches cargo.
- Makes it so that `./mach test-wpt` accepts the exact same arguments
and has the same behavior as other commands. In addition, the suite
correct for `test-wpt` is removed. There are only two suites now and
it's quite unlikely that people will confuse WPT tests for rust unit
tests.
PR #30048 switched `./mach update-wpt` to use 2020 layout engine by default. Since the WPT import job was not passing any flags when updating 2013 expectations, it was not using the correct metadata files, leading to failures when landing the recent [wpt sync PR](https://github.com/servo/servo/pull/30075)
Now that the new version of GStreamer fixes this issue, we can remove
the workarounds for this problem as well as all of the homebrew
bootstrapping logic.
Do not do the duplicate workflow checks for main workflow jobs triggered
by 'issue_comment' GitHub Actions. This prevents try jobs from being
skipped. This issue was not detected in my testing, because the main
workflow does not run in personal repositories and 'issue_comment'
actions cannot be tested from PRs.
This is the last piece of the puzzle to turning off bors. This makes
functionality provided by bors to understand "@bors-servo try" a GitHub
Action. For now the syntax is more or less the same, but we can modify
it in the future and even add support for custom configuration options
(more specific build combinations or even passing compiler flags).
The big difference between this and what bors does is that there is no
merge commit. GitHub simply runs tests on the version of the branch that
is on a pull request. There is always the risk that tests might start
failing when a branch is rebased, but this offers a bit more control
because you can easily rebase from the PR and the merge queue will check
this as well.
Much of the code used to import WPT tests from upstream has been moved
to the WPT repository itself, so this can be reused. In addition,
simplify the workflows by merging the entire process into mach and also
directly into the GitHub workflow. This should fix WPT imports after
combining compilation of layout and legacy layout.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
When the decision job decides that a workflow should be skipped because
an identical one has already run, that workflow should be marked as
successful and not unsuccessful.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
Split the WPT workflow from the Linux one
This allows running tests for only one layout system at a time. This was
originally part of #29950, but was lost in the shuffle.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they improve the CI.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
When using "try-<platform>" trigger unit tests
There is currently no way to trigger unit tests using the bors-servo try
infrastructure. This change makes it so that using try-<platform>
triggers unit tests for that platform. This will be especially useful
when testing changes for Windows before trying to land them.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they are just GitHub Actions changes.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
This PR configures the main workflow (currently
used by bors via auto & try branches) to run
on 'merge_group' events emitted when pull requests
are added to GitHub merge queue.
Signed-off-by: Mukilan Thiyagarajan <me@mukilan.in>
There is currently no way to trigger unit tests using the bors-servo try
infrastructure. This change makes it so that using try-<platform>
triggers unit tests for that platform. This will be especially useful
when testing changes for Windows before trying to land them.
Remove:
- tidy self test support from `./mach test`
- `./mach test-idl`
Adds a `./mach test-scripts` command that is responsible for running all
Python script tests. Run this during the CI to catch regressions in
changes to scripts. The WebIDL tests are still *very* slow and there are
from Gecko, so only run them when "-a" is passed meaning all tests.
Default nightly builds to layout 2020
This PR switches the filenames used by nightly builds so that the default `servo-latest.{ext}` packages use the 2020 engine and the 'servo-latest-legacy-layout.{ext}` packages use the 2013 engine.
Since the platform workflows are reused by the main, quick-check, PR and WPT import flows and since the 2013/2020 flags are also controlled by try branches, I've kept the changes isolated to `nightly.yml` and `package_commands.py` and have avoided changing the input parameters. If we want to deault all the workflows to 2020, I can decline this PR and raise a new one.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they modify packaging logic.
Run unit tests on the main Linux workflow
Not running unit tests on the main Linux workflow makes it faster, but also allows merging changes that break the unit tests. This change fixes that.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because they are CI changes.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
