shaba/ostree
1
0
Fork 0
mirror of https://github.com/ostreedev/ostree.git synced 2025-01-18 10:04:17 +03:00
Code Issues Projects Releases Wiki Activity
ostree/tests/inst/Cargo.toml

44 lines
1.1 KiB
TOML
Raw Normal View History

Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
[package]
name = "ostree-test"
version = "0.1.0"
authors = ["Colin Walters <walters@verbum.org>"]
rust: Switch to 2021 edition No real changes. ``` $ cargo fix --edition note: Switching to Edition 2021 will enable the use of the version 2 feature resolver in Cargo. This may cause some dependencies to be built with fewer features enabled than previously. More information about the resolver changes may be found at https://doc.rust-lang.org/nightly/edition-guide/rust-2021/default-cargo-resolver.html When building the following dependencies, the given features will no longer be used: libc v0.2.126 removed features: extra_traits The following differences only apply when building with dev-dependencies: getrandom v0.2.6 removed features: std ``` which looks OK to me.
2022-06-09 15:55:41 -04:00
edition = "2021"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
build-sys: Adjust for merge of ostree-rs Fix up the paths for the crates now that the Rust bindings are in `rust/`. We can't today include the test suite because it depends on `ostree-rs-ext` which would make everything circular. (Building that now requires a separate `cd tests/inst && cargo build`)
2022-03-31 18:53:31 -04:00
[workspace]
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
[[bin]]
name = "ostree-test"
tests/inst: Add destructive test framework This adds infrastructure to the Rust test suite for destructive tests, and adds a new `transactionality` test which runs rpm-ostree in a loop (along with `ostree-finalize-staged`) and repeatedly uses either `kill -9`, `reboot` and `reboot -ff`. The main goal here is to flush out any "logic errors". So far I've validated that this passes a lot of cycles using ``` $ kola run --qemu-image=fastbuild-fedora-coreos-ostree-qemu.qcow2 ext.ostree.destructive-rs.transactionality --debug --multiply 8 --parallel 4 ``` a number of times.
2020-05-31 17:57:22 +00:00
path = "src/insttestmain.rs"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
[dependencies]
tests/inst: Update cap-std-ext to 1.0
2022-11-22 10:14:17 -05:00
cap-std-ext = "1.0"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
clap = "2.32.0"
tests/inst: Add destructive test framework This adds infrastructure to the Rust test suite for destructive tests, and adds a new `transactionality` test which runs rpm-ostree in a loop (along with `ostree-finalize-staged`) and repeatedly uses either `kill -9`, `reboot` and `reboot -ff`. The main goal here is to flush out any "logic errors". So far I've validated that this passes a lot of cycles using ``` $ kola run --qemu-image=fastbuild-fedora-coreos-ostree-qemu.qcow2 ext.ostree.destructive-rs.transactionality --debug --multiply 8 --parallel 4 ``` a number of times.
2020-05-31 17:57:22 +00:00
structopt = "0.3"
serde = "1.0.111"
serde_derive = "1.0.111"
serde_json = "1.0"
tests/inst: Update sh-inline
2022-11-22 10:14:17 -05:00
sh-inline = "0.4.0"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
anyhow = "1.0"
tempfile = "3.1.0"
tests/inst: Update to latest ostree-ext (And glib, etc.)
2023-08-22 14:23:56 -04:00
ostree-ext = { version = "0.11" }
Update to `libtest-mimic` 0.5.0
2022-08-13 16:14:23 +02:00
libtest-mimic = "0.5.0"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
twoway = "0.2.1"
tests/inst: Update tokio, hyper and nix
2021-04-07 17:43:03 +00:00
hyper = { version = "0.14", features = ["runtime", "http1", "http2", "tcp", "server"] }
tests/inst: Update hyper-staticfile to 0.9.4 Due to some vulnerabilities[1][2], all versions prior to 0.9.4 have been yanked from crates.io. There have been some API changes since 0.6.0, but none of them affect the simple `hyper_staticfile::Static` usage here. 1. https://rustsec.org/advisories/RUSTSEC-2022-0069.html 2. https://rustsec.org/advisories/RUSTSEC-2022-0072.html
2023-01-24 13:18:44 -07:00
hyper-staticfile = "0.9.4"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
futures = "0.3.4"
http = "0.2.0"
tests/inst: Update tokio, hyper and nix
2021-04-07 17:43:03 +00:00
tokio = { version = "1.4.0", features = ["full"] }
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
futures-util = "0.3.1"
tests/inst: Drop nix dependency It has various semver bumps and we were literally just using it to duplicate what's already in `libc`.
2022-11-22 10:12:30 -05:00
libc = "0.2.100"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
base64 = "0.12.0"
procspawn = "0.8"
Update to rand 0.8 Part of general crate updates.
2022-03-11 15:34:59 -05:00
rand = "0.8"
tests/inst: Add destructive test framework This adds infrastructure to the Rust test suite for destructive tests, and adds a new `transactionality` test which runs rpm-ostree in a loop (along with `ostree-finalize-staged`) and repeatedly uses either `kill -9`, `reboot` and `reboot -ff`. The main goal here is to flush out any "logic errors". So far I've validated that this passes a lot of cycles using ``` $ kola run --qemu-image=fastbuild-fedora-coreos-ostree-qemu.qcow2 ext.ostree.destructive-rs.transactionality --debug --multiply 8 --parallel 4 ``` a number of times.
2020-05-31 17:57:22 +00:00
strum = "0.18.0"
strum_macros = "0.18.0"
tests/inst: Switch to rpmostree-client from git See discussion in https://github.com/coreos/rpm-ostree/pull/2569#issuecomment-780569188 Currently pinned to a hash, but after the next stable release let's switch to tags
2021-02-17 21:59:15 +00:00
# See discussion in https://github.com/coreos/rpm-ostree/pull/2569#issuecomment-780569188
tests/inst: Update rpm-ostree client
2021-04-07 17:40:26 +00:00
rpmostree-client = { git = "https://github.com/coreos/rpm-ostree", tag = "v2021.3" }
tests/inst: Add xshell and use it in one place I've deprecated sh-inline; in the end I think it is better to minimize the amount of bash code we have. xshell solves the core convenience problem of taking local variables and mapping them to command arguments. A full port would be nontrivial; this just starts the ball rolling.
2023-05-10 09:21:45 -04:00
xshell = "0.2.3"
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
tests/inst: Add destructive test framework This adds infrastructure to the Rust test suite for destructive tests, and adds a new `transactionality` test which runs rpm-ostree in a loop (along with `ostree-finalize-staged`) and repeatedly uses either `kill -9`, `reboot` and `reboot -ff`. The main goal here is to flush out any "logic errors". So far I've validated that this passes a lot of cycles using ``` $ kola run --qemu-image=fastbuild-fedora-coreos-ostree-qemu.qcow2 ext.ostree.destructive-rs.transactionality --debug --multiply 8 --parallel 4 ``` a number of times.
2020-05-31 17:57:22 +00:00
# This one I might publish to crates.io, not sure yet
Add new Rust-based tests There's a lot going on here. First, this is intended to run nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252). With Rust we can get one big static binary that we can upload, and include a webserver as part of the binary. This way we don't need to do the hack of running a container with Python or whatever. Now, what's even better about Rust for this is that it has macros, and specifically we are using [commandspec](https://github.com/tcr/commandspec/) which allows us to "inline" shell script. I think the macros could be even better, but this shows how we can intermix pure Rust code along with using shell safely enough. We're using my fork of commandspec because the upstream hasn't merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+). This model is intended to replace *both* some of our `make check` tests as well. Oh, and this takes the obvious step of using the Rust OSTree bindings as part of our tests. Currently the "commandspec tests" and "API tests" are separate, but nothing stops us from intermixing them if we wanted. I haven't yet tried to write destructive tests with this but I think it will go well.
2020-03-28 14:04:31 +00:00
with-procspawn-tempdir = { git = "https://github.com/cgwalters/with-procspawn-tempdir" }
Reference in New Issue Copy Permalink