Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
r-n-o
left a comment
r-n-o
left a comment
There was a problem hiding this comment.
I haven't looked at the details of each command, just browsed through top-to-bottom to get a lay of the land. First impression: looks great! 👏
| @@ -0,0 +1,41 @@ | |||
| # Experimental CLI for Turnkey Verifiable Cloud | |||
|
|
|||
| ## Usage | |||
There was a problem hiding this comment.
Something I'm wondering: possible to have e2e tests for tvc CLI? We can start small, but I think having a harness will pay off
There was a problem hiding this comment.
I see them! They're here, but at the very end of the diff (tvc/tests)
🐐
There was a problem hiding this comment.
They are pretty simple for now and don't fully test functionality with the API - but they should at least check basics like the expected arguments
| /// Run the deploy status command. | ||
| pub async fn run(args: Args) -> anyhow::Result<()> { | ||
| println!("Getting status for deploy: {}", args.deploy_id); | ||
| todo!("deploy status not yet implemented") | ||
| } |
There was a problem hiding this comment.
I think this should be possible with the latest protos? There's a GetDeployment endpoint you can leverage. Or maybe you mean kubernetes level status?
There was a problem hiding this comment.
That's a good point. I was originally thinking this would be for k8s type status. We implicitly call GetDeployment in in deploy approve
Maybe what I can do is fill this current stub with GetDeployment, and then we can add another API call and combine the info
tvc/src/config/turnkey.rs
Outdated
| /// API key stored in api_key.json | ||
| #[derive(Debug, Clone, Serialize, Deserialize)] | ||
| pub struct ApiKey { | ||
| /// Hex-encoded compressed public key | ||
| pub public_key: String, | ||
| /// Hex-encoded private key | ||
| pub private_key: String, | ||
| } |
There was a problem hiding this comment.
Might be worth reusing the ApiKey struct from here?
rust-sdk/api_key_stamper/src/lib.rs
Lines 56 to 60 in 06a000d
One thing you're missing if you want this to be generic is the curve / scheme
There was a problem hiding this comment.
- I will add curve so we are more generic
- The idea with this struct is that is represents how its stored on disk. While the TurnkeyP256ApiKey is the abstraction for actually using/generating the p256 key. I'll rename it to StoredApiKey
tvc/src/config/turnkey.rs
Outdated
| /// Operator key stored in operator.json | ||
| #[derive(Debug, Clone, Serialize, Deserialize)] | ||
| pub struct OperatorKey { | ||
| /// Hex-encoded compressed public key | ||
| pub public_key: String, | ||
| /// Hex-encoded private key | ||
| pub private_key: String, | ||
| } |
There was a problem hiding this comment.
Same here I think a scheme could be beneficial. Although...if you make the struct "QOSOperatorKey" it's clear enough that it'll be whatever QOS expects, which is a seed + 2 derived keys
tvc/src/config/turnkey.rs
Outdated
| } | ||
| } | ||
|
|
||
| impl ApiKey { |
There was a problem hiding this comment.
These impl should probably move to their own module so we can test them in isolation
2 participants
Introduce TVC CLI with login, app, and deployment commands
Supersedes
app {init, create},deployment {init, create}, and updatedeployment approve#70