Use production propolis-server flags in PHD CI builds #878
Conversation
We use the dev (e.g. non-release) build of propolis-server in PHD to get debug assertions, which we want, but we should use the `omicron-build` feature to be in line with production binaries. `omicron-build` had also acquired code related to failure injection, which we *also* want in CI so we can test migration failure codepaths. That is moved to a new `failure-injection` feature flag with a bit of ceremony to stop us early if we're ever inadvertently packaging a propolis-server with `omicron-build` and `failure-injection`. Fixes #412.
|
all the failures include propolis-server stderr like there are info logs for VMM allocations and from a passing build we have been saying |
xtask/src/task_phd.rs
Outdated
| // in the system has encountered an error, so enable | ||
| // failure-injection. Do not enable `omicron-build` like we | ||
| // do in Buildomat because someone running `cargo xtask phd` | ||
| // is not building a propolis-server destined for Omicron. |
There was a problem hiding this comment.
Well, unless they are :) I think this was my use case earlier this week, and it may also come in handy if someone wants to try to reproduce a CI failure on a local machine.
Perhaps add an omicron_build switch to PropolisArgs to allow the user to opt into adding that feature?
There was a problem hiding this comment.
..... i suppose cargo xtask phd does build a replacement propolis-server doesn't it.
but yeah, a build to get omicron-build enabled makes a lot of sense. lemme do that.
There was a problem hiding this comment.
in writing 8affc65 i discovered that cargo xtask phd run and cargo xtask phd run --omicron-build ends up with artifacts in different directories. so if you run one, then the other, then the first one again expecting another propolis-server rebuild, it'll actually just run immediately. surprise!
but the test suite passes on my workstation with or without the flag (wherein i have a reservoir configured), everything fails (as expected!) when i set the reservoir too small.
Co-authored-by: Greg Colombo <greg@oxidecomputer.com>
We use the dev (e.g. non-release) build of propolis-server in PHD to get debug assertions, which we want, but we should use the
omicron-buildfeature to be in line with production binaries.omicron-buildhad also acquired code related to failure injection, which we also want in CI so we can test migration failure codepaths. That is moved to a newfailure-injectionfeature flag with a bit of ceremony to stop us early if we're ever inadvertently packaging a propolis-server withomicron-buildandfailure-injection.Fixes #412. I assume the
failure-injectionfeature will be useful for future testing enhancements like #698cargo xtask phd runstill passes with an Alpine guest, waiting to see the same fromphd-run.