Now that Cargo tests are being run on the worker node directly, we can
leave the bare minimum in Travis, which is taking care of the release
deployment.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Reorder the build commands so that more build assets in the target/
build directory can be reused. This will reduce the build time.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
After some of the build changes there was no longer a release artifact
left to be used for the release builds.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
cargo audit audits Cargo.lock for crates with security vulnerabvilities
reported by the RustSec Advisory Database.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Create vhost-user-net backend with Tap interface, to offload network
transaction from cloud-hypervisor. The goal is to provide flexibility
about the backend being in use, but also more security as it will allow
users to isolate the backend with different security profiles since it
will run as a dedicated process on the host.
Signed-off-by: Cathy Zhang <cathy.zhang@intel.com>
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Put the ACPI support behind a feature and ensure that the code compiles
without that feature by adding an extra build to Travis.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
We use cargo vendor to generate a .cargo/config file and the vendor
directory. Vendoring allows us to lock our dependencies and to modify
them easily from the top level Cargo.toml.
We vendor all dependencies, including the crates.io ones, which allows
for network isolated builds.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
"cargo fmt --all -- check" does not check all the other crates in the
repository so replace this with a find command. In the long term it
might be appropriate to use a cargo workspace to solve this problem.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
