* ci: Switch to version 4 of GitHub artifact actions
This switches to version 4 of the GitHub artifact actions, which
requires producing a single artifact per job and adding merge steps. In
addition, the names of artifacts are standardized:
- Build: <profile>-binary-<platform>
- Full WPT results (only on failure): wpt-full-logs-<platform>-<layout>
- Filtered WPT results (only on failure): wpt-filtered-logs-<platform>-<layout>
* Delete merged build timings and combine with Result job
* Always archives logs even after test failures
* Correct the name of the log files for WPT import
* Matrix in CI and mach try with presets
* small fixups
* names in trigger try run comment
* let
* f
* rename step
* fix running try on win
* fix try branch full
* py3.10
* typo
* Make unit-tests default to false, except in basic os runs
Fixes https://github.com/servo/servo/issues/31174
* make full use linux-wpt & linux-wpt also include unit-tests
so full is equal to main workflow
* Stylish fixes
* cmp json as dict
Make it so that all try builds go through try.yml and pass
workflow_call arguments as expected to subsequent workflows.
Co-authored-by: Samson <16504129+sagudev@users.noreply.github.com>
This should prevent multiple `parse-comment` jobs from running at the
same time for the same pull request, reducing the number of duplicate
builds when multiple labels are applied.
Triggering from labels means that we have less actions running and less
false job failures spamming project members. Plus, we have more
flexibility with labels rather than the backward compatibility we have
set up for bors comments.
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.
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.
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.
