Conversation
Codecov Report
@@ Coverage Diff @@
## master #9601 +/- ##
===========================================
+ Coverage 35.48% 63.42% +27.94%
===========================================
Files 332 574 +242
Lines 32620 37648 +5028
===========================================
+ Hits 11575 23880 +12305
+ Misses 19819 11900 -7919
- Partials 1226 1868 +642
|
ryanchristo
left a comment
There was a problem hiding this comment.
Manually tested. Seems to be working without issues. A couple comments.
| require.Equal(t, "keyring-test", backend.PassPrefix) | ||
| } | ||
|
|
||
| func TestRenameKey(t *testing.T) { |
There was a problem hiding this comment.
For each test, should we check more than just an error? Should we also check whether each key does or does not exist within the keyring after renaming?
There was a problem hiding this comment.
Should we also check whether each key does or does not exist within the keyring after renaming?
this is already checked on L1175 and L1182-L1183
There was a problem hiding this comment.
Within this test, rename is called three times at the end without checking the specific error thrown or what keys exist after each failed attempt. I was thinking the extra checks would be added to the failed attempts. At the least, I think we should check to make sure we are receiving the expected error and not just any error.
There was a problem hiding this comment.
refactored the tests. should be a bit more concise. let me know if its missing anything please!
There was a problem hiding this comment.
Nice! I like the direction with adding test cases. I'm not sure if it's necessary given that the only parameter for each test case is the run function and there is no overlap with the key names you are using so creating a new keyring for each test case might not be necessary but I also think it's ok to leave it as is.
Co-authored-by: likhita-809 <78951027+likhita-809@users.noreply.github.com>
| return errors.New(fmt.Sprintf("rename failed: %s already exists in the keyring", newName)) | ||
| } | ||
|
|
||
| passPhrase := "temp" |
There was a problem hiding this comment.
nit: this should be a private const
There was a problem hiding this comment.
yup that makes much more sense - moved it to the other private const vars
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
| err = ks.Delete(oldName) | ||
| if err != nil { | ||
| return err | ||
| } |
There was a problem hiding this comment.
Should this be called after ImportPrivKey? What happens if ImportPrivKey fails? The account is deleted and no new account is created.
There was a problem hiding this comment.
so import will actually fail if you delete last, cause import doesn't allow same pubkeys. some solutions i can think of:
-
dump the key information in a recovery file
-
update the ImportPrivKey method to allow keys with same pubkeys, but different keyring names
thoughts?
There was a problem hiding this comment.
If the name is the primary index, I think it's OK to go with (2).
There was a problem hiding this comment.
alright, changed the write behavior to allow duplicate keys, as long as the names are different.
ryanchristo
left a comment
There was a problem hiding this comment.
tACK. No necessary changes but I left a few comments.
| require.Equal(t, "keyring-test", backend.PassPrefix) | ||
| } | ||
|
|
||
| func TestRenameKey(t *testing.T) { |
There was a problem hiding this comment.
Nice! I like the direction with adding test cases. I'm not sure if it's necessary given that the only parameter for each test case is the run function and there is no overlap with the key names you are using so creating a new keyring for each test case might not be necessary but I also think it's ok to leave it as is.
Co-authored-by: Ryan Christoffersen <12519942+ryanchristo@users.noreply.github.com>
Co-authored-by: Ryan Christoffersen <12519942+ryanchristo@users.noreply.github.com>
|
the change request is blocking merge @alexanderbez, could you re-review when you have time? |
|
@alexanderbez ping - still blocked 🙈 |
Description
this PR adds a new function to the keyring interface, as well as a CLI command to rename a key in the keyring
ref: #9407
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!to the type prefix if API or client breaking changeCHANGELOG.mdReviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!in the type prefix if API or client breaking change