Before being able to switch the Cloud Hypervisor code base to use vhost-user-backend as an external crate, we must ensure that any code that's merged into the vhost-user-backend has passed the Cloud Hypervisor integration tests. A few options:
Cloud Hypervisor CI trigger: Something a la dependabot, where any new vhost-user-backend PR would send a notification to the Cloud Hypervisor repo and trigger an action that would create a Cloud Hypervisor PR using the pending vhost-user-backend code.
Decouple the Cloud Hypervisor functional tests and CI from the Cloud Hypervisor repo itself. This new project would take any Cloud Hypervisor code base and run the functional tests on it. A pending vhost-user-backend (or any other external repo that we control) PR could then generate a new CLH code base using said PR and independently run the integration tests against it.
Before being able to switch the Cloud Hypervisor code base to use vhost-user-backend as an external crate, we must ensure that any code that's merged into the
vhost-user-backend
has passed the Cloud Hypervisor integration tests. A few options:Cloud Hypervisor CI trigger: Something a la dependabot, where any new
vhost-user-backend
PR would send a notification to the Cloud Hypervisor repo and trigger an action that would create a Cloud Hypervisor PR using the pendingvhost-user-backend
code.Decouple the Cloud Hypervisor functional tests and CI from the Cloud Hypervisor repo itself. This new project would take any Cloud Hypervisor code base and run the functional tests on it. A pending
vhost-user-backend
(or any other external repo that we control) PR could then generate a new CLH code base using said PR and independently run the integration tests against it.