This is somehow introduced in #43617. This is causing CI failure.
For whatever reason, this thing should only be in `.git` folder. But
somehow it is at the root?
Also changed `.yml` to avoid ambiguity: we are using revision instead of
path.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
Since https://github.com/servo/servo/pull/44182 production builds for
android are now possible in CI.
Let's unify this, since all other platforms already use production. The
production build is also ~45MB small, which is a huge reduction compared
to the ~159MB our nightly builds have. I didn't investigate further why
the difference is that large, but I installed the production version on
my phone and didn't spot any obvious issues (on servo.org).
[Mach try
android-production](https://github.com/jschwe/servo/actions/runs/24525178123)
Testing: We don't test CI workflows themselves.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Also build an arm64 version of the devcontainer and combine both into a
multi platform image.
This also fixes the upload step, which was broken on main by
b5d454eca0.
We also allow triggering the publish job on forks via manual workflow
trigger, which allows more convenient testing.
[Manually triggered
workflow](https://github.com/servo/servo/actions/runs/24336772082)
Testing: This is a CI change.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
The publish environment enforces additional restrictions, mainly that
the workflow can only be run from protected branches and additional
prevents access of the publish secrets from workflows which do not use
this environment.
Testing: Requires a manual workflow run on a protected branch. Given
that we already tested environments in previous PRs, I think this PR
might be safe to test after merging, instead of protecting the PR
branch.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Using the new yaml anchor feature, we can inline the upload_release
workflow file without duplicating code.
In combination with the matrix feature this allows us to remove quite a
bit of duplication. I'm not sure why we didn't use matrix to begin with.
This is also a preparation for a follow-up PR, that uses github
environments to improve secret protection, since reusable workflows
don't support environments.
Testing: [manually triggered nightly
release](https://github.com/servo/servo/actions/runs/24236862409)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
When triggering the release action on a non-protected branch in this
repo, the job is rejected (as intended):
<img width="1484" height="304" alt="image"
src="https://github.com/user-attachments/assets/236d3a41-2765-4652-8709-93110e03c77b"
/>
When triggering the action on a protected branch in this repository, the
publish-crates-io job will be pending, until explicitly approved by one
of the required approvers (thanks to the `environment` settings).
This allows us to publish all of our packages in one go.
Testing: Tested by manually
[triggering](https://github.com/servo/servo/actions/runs/24119955943/job/70371705395)
a release for `0.1.0-rc2`, which got successfully published to
crates.io. This was also a resume-after-cancellation test, since the
first ~30 crates of the release had already been published via `cargo
publish --workspace`, before running into the issue that `cargo publish
--workspace` can't resume after intermediate failures. The last commit
"Fix buffering issue in CI" is untested, and was added after observing
the stdout log messages only appearing at the end of the script. That
commit is trivial though, and probably does not justify using crates.io
resources for another test release.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
Co-authored-by: Mukilan Thiyagarajan <mukilanthiagarajan@gmail.com>
If we make manual releases, e.g. for release candidate testing, then
they shouldn't appear on the nightly download page on servo.org, which
just displays the release that is marked as "latest".
Since the Github API documentation updated to a new API version, also
opt-in to the new version while we are at it.
There seem to be no changes affecting the usage in release.yml, but
probably the old API will be removed eventually, so why not switch to
the new version now.
See
https://docs.github.com/en/rest/releases/releases?apiVersion=2026-03-10#create-a-release
Testing: [Manual release workflow
run](https://github.com/servo/servo/actions/runs/24241705213). The
release should not be marked as latest after the run finishes.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We defined a github environment `book-sync` which contains the required
secrets.
After merging this PR we can remove the secrets from the per-repository
secrets, which reduces the scope the secrets are available in, and has
the added restriction of only being available on protected branches.
Testing: Prior to this PR, the functionality was tested on the
`environments` branch and discussed in the maintainers chat. After this
PR is merged, a manual check should be done to ensure the book-export
workflow still continues to work as expected.
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This partially reverts 017b12a627. The
intermittent issues should be resolved now.
./mach build --release results in ~3GiB of sccache size locally. Since
we build multiple configurations (with crown, tests, profiles) we will
easily hit the 10GiB cache limit even with just one architecture. Hence,
it doesn't make sense to add sccache to more workflows, at least not
before we decide to buy more cache or not.
This should hopefully make the macos-arm64 workflows faster. Locally the
speed-up on clean builds is significant.
Testing: [mach try (no existing
cache)](https://github.com/jschwe/servo/actions/runs/23507308462/job/68418624068),
[mach try
#2](https://github.com/jschwe/servo/actions/runs/23508733572/job/68423715413)
- i.e. 34 minutes vs. 19 minutes total runtime, and 30 m vs 15 m build
time (with ideal conditions for the caching)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Testing: Not tested, it's difficult to test try-label related changes.
The fix is trivial though.
Fixes: #43345
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
the `-p servo` (formerly libservo) lib target was busted for anyone
genuinely consuming it as a library, but we didn’t catch it because the
CI job designed to check it built `-p servo` with --all-targets, which
unlike library consumers pulls in [dev-dependencies].
this patch fixes the compile error, and fixes the CI check to build `-p
servo` in a more realistic configuration.
Testing: tested in CI, and locally with `cargo build -p servo --locked`
Fixes: #43168
Signed-off-by: delan azabani <dazabani@igalia.com>
#43114 made the action error if the artifact is not found, which exposed
an issue with uploading the wrong path. We don't really care about
uploading the x86_64 version of the ohos library, since it is not used
in the release (not now at least), but it's better to fix the condition
anyway.
Fixes nightly upload failures like in
https://github.com/servo/servo/actions/runs/22927035640/job/66539862051
Testing: Not tested
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
As discussed on zulip we would like to rename `libservo` to `servo`
(again) before a future crates.io release.
Servo is a library, so the `lib` prefix is somewhat redundant. We
already renamed the binary of ServoShell to `servoshell`, to reduce
confusion of users of what servo is.
Note: This PR does not touch all occurrences of `libservo`. Specifically
CI job names remain untouched, since the risk of breaking something is
higher here, harder to test for and the name not user facing.
Testing: CI testing of this change should give us good confidence.
Manual testing of `./mach doc` and `./mach build` showed no issues on
macos. [Full try
run](https://github.com/jschwe/servo/actions/runs/22909562747)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
- Rename instead of copy the `cargo-timings` folder
- Fail the action if artifact not found in upload-artifact. This should
prevent things like #43102
- Update `actions/upload-artifact` to v7
Testing: If this can merge, it is successful.
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
Follow-up to https://github.com/servo/servo/pull/41775
This allows syncing our package list to the book automatically, keeping
the documented required packages in sync with what bootstrap installs.
We use two personal access token of the `servo-bot` account. One PAT
with the Resource-owner `servo-bot` for the repository `servo-bot/book`,
to push the branch to the bots fork. This PAT should be created with the
following permissions:
Choose "Only select repositories", select the forked book repo and give
the token Contents: Read and write permissions.
The second PAT must have the resource owner `servo`, and access to the
repository `servo/servo` as well as the permissions "Pull-Request: Read
and Write".
This split has the advantag of limiting the PAT permissions for the
upstream repo, avoiding `Content: Write` permissions for the
`servo/book` repository.
Testing: Manually tested by letting the action run on this branch.
[successfull
run](https://github.com/servo/servo/actions/runs/22387422307/job/64800999782?pr=42063),
[created upstream PR](https://github.com/servo/book/pull/207)
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Signed-off-by: Jonathan Schwender <55576758+jschwe@users.noreply.github.com>
Co-authored-by: shuppy <dazabani@igalia.com>
Renaming the job in #42929 silently broke the evaluation here.
Testing: Can only be tested on main / in priviledge contexts / otherwise
the unsigned binary is anyway built.
Fixes: ohos bencher failing on main (since the wrong binary name is
chosen)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Renaming the openharmony build job in #42929 caused artifact_ids to be
empty, which caused release failures.
Additionally, we add a validation step to the upload workflow, to
quickly pinpoint the issue of a missing input parameter,
since apparently github won't throw an error if a required input
parameter is empty.
This should make it easier to pinpoint the issue if it happens again.
Testing: Not tested.
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
This is a preparation for publishing to crates.io. Changes include:
- Add `servo-` prefixes to avoid name collisions on crates.io
- Use `-` instead of `_` in package names.
- Rename the crates to their original names in Cargo.toml,
to keep the diff minimal
- Rename `media` to `servo-media-thread` to avoid name collision with
`servo-media` (originally from the media repository).
This is an outcome of the previous discussion at [#general > Switch
remaining git dependencies to
crates.io](https://servo.zulipchat.com/#narrow/channel/263398-general/topic/Switch.20remaining.20git.20dependencies.20to.20crates.2Eio/with/576336288)
Testing: This should be mostly covered by our CI, but some amount of
breakage is to be expected, since some package names could still be
referenced from scripts which are not tested or run in CI. [mach try
run](https://github.com/jschwe/servo/actions/runs/22502945949)
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
There's some hanged scenarios with mitmproxy:
https://github.com/servo/servo/actions/runs/22539387007/job/65292396178
1. We rename `build` to `build-openharmony`.
2. We add
- 60 minutes timeout for each Build profile
- 40 minutes for bencher (Normally finish under 10 mins)
- 20 mins for scenario tests. (Normally finish under 4 mins)
---------
Signed-off-by: Euclid Ye <yezhizhenjiakang@gmail.com>
WPT creates `epochs/daily` either at 2 or 3AM. This means that if a fix
land on day 1, then WPT is tagged earlier than the nightly release, so
it can take 24-48 hours before a change is reflected on wpt.fyi
If instead we create the nightly release in time before epoch, we can
see those results within 24 hours.
Testing: GitHub workflow change
---------
Signed-off-by: Tim van der Lippe <TimvdLippe@users.noreply.github.com>
That respects the user locale better than hardcoding en-US. This can
also be manually set with the `LANG` environment variable.
Testing: Manual testing with the devtools to check the header sent and
the value of `navigator.language`
Signed-off-by: webbeef <me@webbeef.org>
The workflow is now used both for regular releases and nightly releases.
Testing: Not tested, it's a simple rename and nothing should rely on the
name `nightly.yml` (grep search)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
We now use a replay recorded via mitmproxy to run the benchmarks.
1. Check the GitHub cache for a mitmproxy dump.
2. If it does not exists create it with update_mitmproxy_dump and store
it in the GitHub cache
3. Run mitmproxy in Replay mode instead of Forward mode with the above
given dump.
This should reduce the jitter of tests that depend on network.
This works currently for the scenariotests and speedometer with
hitrace-bencher soon to follow.
Testing: Tested with two separate runs.
https://github.com/Narfinger/servo/actions/runs/21828840808 has the
cache already populated.
The noisy output of mitmdump actually shows that it is answering the
queries from replay for all scenario tests.
https://github.com/Narfinger/servo/actions/runs/21831381306/job/62991977638
shows how before the scenario tests the cache is created and stored.
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Update ohos.yml hitrace-bench and runs.json to 0.10.0
Testing: This should be testing using CI
Signed-off-by: jane <5373400+janeoa@users.noreply.github.com>
This updates the Openharmony required version to API lvl 21 (6.0.0.1
OpenHarmony and 6.0.1 HarmonyOS).
We need API level 19+ for https://github.com/servo/servo/pull/41738,
however an API level 19 SDK was never released for OpenHarmony. API-20
seems to be the same as the the 6.0-beta release, so we are playing it
safe and directly going for the API-21 release, which is also the 6.0.1
release that the actual HarmonyOS 6 update was, so it should be the most
polished.
This also has the update for the version used in CI.
The HarmonyOS runners are already updated.
Testing: Successful openharmony run here:
https://github.com/Narfinger/servo/actions/runs/21755920480
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Smoketest is subsumed by scenario test and can be removed.
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
Testing: *Describe how this pull request is tested or why it doesn't
require tests*
---------
Signed-off-by: Narfinger <Narfinger@users.noreply.github.com>
This change merges http://github.com/servo/media into this repository.
It is only used by Servo and version upgrades are complicated by having
two repositories. In addition, this avoids the need to refer to
individual commit hashes in the Servo `Cargo.toml`. The hope is that
merging these two repositories will lead to better code organization /
simplification like we have seen with the WebXR support. Initiailly, the
idea was that this media support could be shared with the wider Rust
ecosystem, but I think that hasn't worked out as planned due to the fact
that it is difficult to use the various media packaes outside of the
Servo project and the fact that no one seems to be doing this.
Some changes were made when importing the code:
- The second commit in this PR addresses new clippy warnings from the
imported code.
- GStreamer Packages are no longer renamed in the media code, so that
they are named the same as they are currently in Servo.
- Some examples are not ported as they require being run interactively
and depend on older version of important libraries like winit.
Having these dependencies in the core part of Servo isn't very
convenient. Removed examples:
- `audio_decoder.rs`: This is meant to be run interactively with a
file so isn't very useful for testing.
- Depended on winit GUI (`player` subdirectory):
- `media_element_source_node.rs`
- `play_media_stream.rs`
- `simple_player.rs`
- `muted_player.rs`
- `siple_webrtc.rs`: Depended on `webrtc` library:
Testing: This is covered by existing tests. In addition, the job which
runs
the media examples is added to the unit test workflow.
---------
Signed-off-by: Martin Robinson <mrobinson@igalia.com>
