Replace existing CI files with a consolidated one to delay starting
resource intensive CI jobs until after less resource intensive ones have
completed: e.g. don't start integration tests if the basic build tests
fail.
Architecture:
- Trigger on [pull_request, merge_group]; concurrency keyed per PR/ref.
- preflight job classifies changed paths and exposes a 'full' flag that
gates the heavier build/quality/integration suite. Any CI change
classifies itself as full so it is exercised.
- Leaf jobs gate at the job level using preflight outputs; doc-only,
openapi-only, dockerfile-only and similar PRs skip the full suite.
- integration-x86-64-pr runs the (garm-jammy, gnu) slice on PR and MQ;
integration-x86-64-mq runs the other 3 matrix entries on MQ only.
- integration-{arm64, vfio, windows, rate-limiter} are MQ-only.
- integration jobs gate on dco/quality/build success.
- A single all-green aggregator job is the only required-status check;
it folds in every leaf job via `needs`.
Assisted-by: Claude:Opus-4.7
Signed-off-by: Rob Bradford <rbradford@meta.com>
Move the live migration test running from their own script into the
x86-64 script (on aarch64 they were already in the same script.) They
were historically separate as they were new. Now they are established it
makes sense for them to be combined.
The timeout in the GitHub workflow has been extended to accommodate the
extra work in the same step.
The Rust test scopes are unchanged - the running of the tests has been
moved.
Assisted-by: Claude:Opus-4.7
Signed-off-by: Rob Bradford <rbradford@meta.com>
Increase the number of parallel integration tests in CI to save ~3-5
minutes per x86_64 run. The thread limit is driven by RAM and disk
space constraints, not CPU availability.
A new `PARALLEL_INTEGRATION_TESTS_NUM` environment variable controls
the thread count. In CI it is set explicitly (12 for x86_64, 25 for
ARM64); locally it falls back to `nproc / 4`, preserving the previous
behavior.
Only the first test group (`common_parallel`, `live_migration_parallel`)
uses the overridden value - subsequent groups (dbus_api, fw_cfg,
ivshmem, aarch64_acpi) continue to use the `nproc / 4` default.
On-behalf-of: SAP philipp.schuster@sap.com
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
Add build and clippy jobs for kvm+sev_snp+igvm+fw_cfg feature combination.
Signed-off-by: Keith Adler <kadler@cloudflare.com>
Signed-off-by: Ruben Hakobyan <hruben@meta.com>
Remove the pinned cross-version commit hash from all
houseabsolute/actions-rust-cross usages. The pin was added as a
workaround for virtio-bindings build issues that have since been
resolved upstream.
Closes#7180
Signed-off-by: Keith Adler <kadler@cloudflare.com>
The updated image is configured in a same way as the
previously used 2022.
SAC, SSH, and RDP are configured.
All Windows updates to the curent date are installed.
Includes latest stable virtio-win 0.1.285 drivers.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
This is a preexisting bug in the MSHV integration tests,
but previously it only caused a warning. With commit
Fixes: 5b67b8994a ("ci: Use set -eufo pipefail") it becomes an error.
Fixes: 5b67b8994a ("ci: Use set -eufo pipefail")
Fixes: #7996
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Workflow runs fail in the "Get Location" step with:
jq: error (at <stdin>:9): string ("100") and number (0) cannot be added
Use tonumber to explicitly convert string to number instead of the "+ 0"
trick.
Signed-off-by: Anirudh Rayabharam <anrayabh@microsoft.com>
Unfortunately with a single ARM64 machine this has now become a
bottleneck for landing PRs. Copy the methodology we use for existing
jobs that we only run on the MQ by creating dummy jobs that run on the
GH hosted runner (ubuntu-latest) allowing the PR to transition into
the MQ by passing the required checks.
Signed-off-by: Rob Bradford <rbradford@meta.com>
This gives the community more time to react to possible security chain
compromises.
We have high confidence that rust-vmm crates are trusted, and the
community is fully capable of spotting any issues. There is no need to
delay that group.
Signed-off-by: Wei Liu <liuwe@microsoft.com>
The MSHV tests need access to secrets so that they can run workloads in
Azure. It does not need privileged access to GitHub. Ensure its
GITHUB_TOKEN has no permissions.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Switch the workspace ownership fix from 'runner' to 'github-runner'
to match the new dedicated service account used on the self-hosted
VFIO runner.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
Skip micro_ prefixed tests in the metrics CI workflow to avoid
dashboard pollution. They can still be run on demand via
--test-filter micro_.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
TL;DR: Would reduce CI pressure by cancelling more "unnecessary" runs
but I can't verify without running a merge queue.
A common development pattern is to push a change and then immediately
check CI results. Follow-up fix pushes are quite common, which leads to
multiple CI runs being queued for the same pull request.
In Cloud Hypervisor, the size and cost of the CI matrix means that
several consecutive pushes (for example 3-4 in a short time) put
significant pressure on CI runners and noticeably increase feedback
latency.
In practice, concurrency handling is especially tricky for the merge
queue. From personal experience: If one does not take special care, CI
runs triggered by a `merge_group` can cancel each other, as in a merge
queue there are two runs for each job by default: one for the normal PR
and one for the merge commit. This is easy to run into, also because the
available documentation and best practices for this feature are not very
good.
At the same time, our workflows do not run on `push` events, but only
on `pull_request` and `merge_group`. Because of this, using
`${{ github.ref }}` alone as a concurrency key is not very meaningful,
and in practice only few runs are actually cancelled for successive PR
updates. Therefore, we should improve the usage of this feature.
This change tries to improve the situation by refining the concurrency
group key. The goal is to keep cancellation for multiple PR pushes,
while at the same time preventing unintended cancellations in the merge
queue by separating `merge_group` runs from regular PR runs.
Signed-off-by: Philipp Schuster <philipp.schuster@cyberus-technology.de>
On-behalf-of: SAP philipp.schuster@sap.com
