-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teleporter CLI #137
Teleporter CLI #137
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good, this will be a great tool to have! I have two high level requests:
-
Can you add unit test suites for the CLI commands? This will also serve as documentation of how to call the CLI commands for easy testing.
-
Can you modify the
golang-ci lint
job to lint thecli/
directory as well? We should still skipabi-bindings/
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to submit these too.. So sorry 😓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Only one small thing you could consider - I think most cli implementations I've seen add the child to the parent in the parent's init function. This way you have all the children in one place, and you can follow the tree structure down if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM. I wasn't previously familiar with cobra so not sure of all the best practices as related to it, but seems like the perfect use case for it, and playing around with the CLI feels very intuitive 👍
dd3a74b
Added some basic unit tests for the CLI and other files. For the CLI unit tests running into issues when the tests are run altogether, likely due to them having shared state, and possibly the commands not reinitializing between tests. Deferring the additional test cases to new issue #174 |
} | ||
} | ||
|
||
func rootPreRunE(logLevelArg *string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly dumb question, but what's the E
suffix denote here and in callPersistentPreRunE
, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In cobra
cli there's commonly functions with an extra E
suffix as duplicates, i.e. PersistentPreRun
vs PersistentPreRunE
. The one's with E just mean return an error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with Cobra, but it generally makes sense to me.
Why this should be merged
Fixes #96
How this works
Creates a cobra command cli that integrates with the Teleporter protocol. The command supports three initial subcommands:
event
: Passing in--topics
and--data
, parses into the corresponding Teleporter event, does not require Teleporter contract address or rpc urlmessage
: Passing in Teleporter message bytes, parses into correspondingTeleporterMessage
, does not require Teleporter contract or rpc urltransaction
: Passing in a transaction hash, Teleporter contract address, and rpc url, filters through the transaction's receipt for any Teleporter or Warp log event.Since the command uses the generated abi bindings, it must be used with data that was generated with same abi, i.e. same version of Teleporter.
How this was tested
Copied and adapted cli to previous commit deployed on firedrillt/secondfire subnets, and tested with transactions on those chains.
How is this documented
README
comments