* 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.
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>
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.
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.
Implement `bootstrap-gstreamer` for all platforms
This change makes it so that the Platform classes can now handle installing GStreamer dependencies and properly setting up the environment including when cross-compiling. For Windows and Linux, prepackaged GStreamer is now installed into `target/dependencies/gstreamer` when not installed system-wide. In addition this change:
1. The Environment path append helper is moved to `util.py` and a new `prepend` version is added.
2. `set_run_env` and `build_dev` functions are combined and include more code from callers so environment setup is more often in the same place. Now code that used to call `set_run_env` calls `build_dev` and then `os.environ.update(...)`. We can further refine this with the `is_build` argument later.
4. Python typing information is added in many places.
<!-- 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 fix#25335
- [x] These changes do not require tests because they are to the build scripts.
<!-- 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 change makes it so that the Platform classes can now handle
installing GStreamer dependencies and properly setting up the
environment including when cross-compiling. For Windows and Linux
is now installed into `target/dependencies/gstreamer` when not installed
system-wide. In addition:
1. Creating and moving existing environment path append helpers to
`util.py`.
2. Combining the `set_run_env` and `build_dev` functions and moving
some outside code into them so that it can be shared. Now code that
used to call `set_run_env` calls `build_dev` and then
`os.environ.update(...)`.
3. Adding Python typing information in many places.
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
We'd like to start offering servo nightly builds
with layout 2020 engine so that users can test
the new layout without building servo. These new
builds will be offered in addition to the current
2013 builds until we switch over to 2020 as the default.
Use ccache on windows workflow
Because `sccache` is not working when setting `CCACHE=sccache` I used ccache which is taking cache hits.
I would certainly love to share some timings, but I found out that windows builds have very inconsistent timings.
Use GStreamer in Windows workflow
I accidental came across https://github.com/servo/servo/projects/26 and can't helped but to fix one. (Few were already fixed but not closed).
Test run: https://github.com/sagudev/servo/actions/runs/4687138840/jobs/8306052042
---
<!-- 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 fix#28277
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it is only 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. -->
This change extends the `mach upload-nightly` command to
publish the nightly builds for all platforms as GH Release
assets.
The GH releases are made on a separate repository so
that we can persist older nightly builds without having
to accumulate git tags for them.
Some design tradeoffs in this approach are:
1. To allow the 'latest' link from servo.org to remain stable,
the release assets are named 'servo-latest.{ext}' instead of
containing the release tag/date.
2. The release is created as draft and published atomically
when all platforms have been built successfully. This allows
us to link to the 'latest' alias from servo.org while
gauranteeing that it contains builds for all platforms.
The other option here would be to have code in servo.org UI
that uses GH API to find the most recent release with a
successful build for a given platform.
3. The tags in the nightly repo are all based on the same
commit that has no relation to servo code base.
Signed-off-by: Mukilan Thiyagarajan <me@mukilan.in>
Secrets need to be passed to reusable workflows either
by name or by `secrets: inherit` from the caller workflow.
The latter allows accessing all secrets in scope.
Windows build has a bug where the upload-nightly command is
not run from the correct working directory.
Closes#29614
Signed-off-by: Mukilan Thiyagarajan <me@mukilan.in>
