This fixes spurious test results due to expectations not
reflecting the PR that is being tried. This change was made to other
files, but not the ones that ran tests.
* Run main and try jobs with debug assertions
* use single quotes in workflow expressions
* set force-debug-assertions in main.yml
* set force-debug-assertions as part of decision job
* fix typo in MachCommands.build
* fix more hardcoded profile names
* fix tidy
* split cargo_profile_option on windows
* Fix running servoshell and unit tests through a symlink
* rename steps to make them less confusing
* fix more hardcoded cargo profile options
* fix missing inputs in linux-wpt and mac-wpt
* make filename an inherent method of Resource
* rework release-with-debug-assertions profile to production profile
* rework resource logic to eliminate std_test_override
* set production flag in nightly release builds
* clean up servobuild.example and windows.yml
* oops forgot to check in embedder_traits/build.rs
* fix mach test-unit behaviour through symlink
* unit tests only need current_dir and ancestors
* fix macOS package smoketest breakage
* expect css/css-color/currentcolor-003 to crash under layout 2013
* fix more references to {force,release-with}-debug-assertions
* fix local build failures under --profile production
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.
The dependabot configuration contained some number of ignored versions
that date from when GitHub dependabot support was added. These versions
fall into three categories:
- Versions that are older or the same version as the version we use.
- Versions that are newer than the versions we use.
- Versions for crates we no longer depend on.
This change removes all ignored versions and updates dependencies in
the second category.
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.
