reconfigurator-cli should support setting target release
#8283
Conversation
Also remove now-superfluous `OrderedComponent` enum.
…rsions' into dap/reconfigurator-cli-tuf-repo
…rsions' into dap/reconfigurator-cli-tuf-repo
| // This test is special-cased because it requires custom setup (creating a TUF | ||
| // repo). | ||
| #[tokio::test] | ||
| async fn test_target_release() { |
There was a problem hiding this comment.
FWIW I'd consider changing the script function in test-scripts.rs to do this behavior if the path ends with target-release.txt.
There was a problem hiding this comment.
Yeah, I considered that at first and I do think it'd work. But it felt pretty ad hoc: "if this test has this name, then we know it needs this extra functionality, so go do it". It seemed clearer to me to be explicit, having a separate test that, from the top level, does the setup it needs and then invokes the common code. I could see this being uglier if we expect to have more tests like this. But if we go down that path, I still think it'd be clearer to use separate test functions that do separate things. e.g., I'd have separate test binaries for tests that need different behaviors. Each would have its own datatest harness that grabs the tests it covers. That seems more explicit than keying off the test filename from inside the test... but it's probably about the same either way.
There was a problem hiding this comment.
Yeah, could go a few ways on this:
- same datatest-stable invocation, different logic by file name
- regular tests in another binary
- different datatest-stable invocations
I don't have very strong opinions here so happy to defer to you and/or revise this later if we notice patterns.
| @@ -0,0 +1,68 @@ | |||
| # Load example system | |||
| load-example --nsleds 3 --ndisks-per-sled 3 | |||
There was a problem hiding this comment.
Since you're not testing any of the zone stuff, I believe, you may be able to make this diff much smaller by passing in --no-zones.
There was a problem hiding this comment.
That's true but I don't view the size of this file as a major problem. I'd rather minimize divergence from an ordinary system. I do think we should really make blueprint-diff skip over stuff that hasn't changed though.
…igurator-cli-tuf-repo
…igurator-cli-tuf-repo
…igurator-cli-tuf-repo
| // Turn the path into an absolute one, because we're going to set a custom | ||
| // cwd for the subprocess. |
| // This test is special-cased because it requires custom setup (creating a TUF | ||
| // repo). | ||
| #[tokio::test] | ||
| async fn test_target_release() { |
There was a problem hiding this comment.
Yeah, could go a few ways on this:
- same datatest-stable invocation, different logic by file name
- regular tests in another binary
- different datatest-stable invocations
I don't have very strong opinions here so happy to defer to you and/or revise this later if we notice patterns.
davepacheco
force-pushed
the
dap/reconfigurator-cli-tuf-repo
branch
from
58ac962 to
93c32ac
Compare
To be able to use
reconfigurator-clito exercise upgrade-related planning, it needs metadata about TUF artifacts available to it. This change addsset target-release /path/to/tuf_repo.zip, which reads a TUF repo zip file, unpacks it into a temporary directory, and extracts the metadata. (This is a little overkill but it's easy to do.) You can also see the metadata withshow.Depends on #8273.
Note that the vast, vast majority of the change here is in one test's expected stdout file.