-
Notifications
You must be signed in to change notification settings - Fork 565
Add CI workflows to validate CH on Microsoft Hypervisor #7381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add workflow to setup Azure infra to validate MSHV. This is used to provision the environment before executing tests on it. Signed-off-by: AASTHA RAWAT <[email protected]>
Add workflow to run integration tests on mshv. It calls the azure infra setup workflow and executes integration tests in the provisioned environment. Signed-off-by: AASTHA RAWAT <[email protected]>
Use mshv runner for mshv workflows. Disable manual trigger. Signed-off-by: AASTHA RAWAT <[email protected]>
| fi | ||
| done | ||
| sudo ./scripts/dev_cli.sh tests --hypervisor mshv --integration -- -- --skip common_parallel::test_tpm --skip common_parallel::test_cpu_topology_421 --skip common_parallel::test_cpu_topology_142 --skip common_parallel::test_cpu_topology_262 --skip common_sequential::test_snapshot_restore_basic --skip common_sequential::test_snapshot_restore_with_fd --skip common_sequential::test_snapshot_restore_pvpanic --skip virtio_net_latency_us --skip common_parallel::test_cpu_hotplug |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be this skips tests could be retrieved from somewhere else, like a environment variable or a file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this can be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What value would it add?
I imagine this list would shrink over time, so would it really be worth it?
Also, how would the environment variable be set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What value would it add?
I imagine this list would shrink over time, so would it really be worth it?
Also, how would the environment variable be set?
Not that much of value just clean code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should disable the tests in integration.rs file may be. @likebreath ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the integration.rs file we do have some build time filtering of tests that don't work on mshv. You will need to make sure you just pass the --no-default features --features mshv when running/building the tests. You can still use a CH binary that is both kvm and mshv - we just want to conditional build the test suite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think since this CI will be still testing mode for some time, we can merge this as now and work in parallel to make changes in integration.rs and eventually remove these tests from here. We should create an issue @gamora12 and start working. @rbradford ??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's fine by me. I'm already working on it; I can raise a separate PR for these changes as well.
Pull requests from forked repos cannot access GitHub secrets which results in failure of MSHV CI. Switching to pull_request_target resolves this. It allows the workflow to run with access to repo secrets and ensures that code from the base branch is used instead of forked code, preventing potential security risks. Signed-off-by: AASTHA RAWAT <[email protected]>
cff8354 to
27db884
Compare
| branches: | ||
| - test_mshv_ci | ||
| pull_request: | ||
| on: [pull_request_target, merge_group] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not recommended to use this - from the docs:
This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request
We should run on merge_group as then the code has already been reviewed and can be sure isn't extracting secrets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With pull_request_target, the CI will only run the base repository code. Even if someone tries to introduce code change that accesses secrets, the code won't be run until it's merged. The runner vm has access to the secrets but it only runs the workflow code (not the PR code), the cloud-hypervisor code will be run on a separate azure vm (which doesn't have access to secrets & can't label or comment on PR), so we're actually safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah - yes! Because dev_cli.sh is run inside a separately created VM. I'm happy if you're happy with that.
|
@likebreath this should be fixed by updating the secret I've shared with you. |
Add workflows for running tests on MSHV using Azure infrastructure.