feat: Trigger tedge multicall with symlinks as well as sub-commands#3313
Conversation
Codecov ReportAttention: Patch coverage is Additional details and impacted files📢 Thoughts on this report? Let us know! |
Robot Results
|
crates/core/tedge/src/main.rs
Outdated
| fn redirect_if_multicall(cmd: TEdgeOpt, common: CommonArgs) -> TEdgeOptMulticall { | ||
| match cmd { | ||
| TEdgeOpt::Mapper(opt) => { | ||
| TEdgeOptMulticall::Component(Component::TedgeMapper(opt.with_common_args(common))) |
There was a problem hiding this comment.
We have to be more cautious here: there is a risk of confusion as --tedge-config is provided twice to clap.
There was a problem hiding this comment.
I assume you mean --config-dir
There was a problem hiding this comment.
When a given global argument (as --config-dir) is used twice by the command struct (as here where common can be accessed directly (common) or via the mapper options (opt.common), clap correctly duplicate the user provided info to all the inner components.
- Hence, there is no need to explicitly copy to common arg.
- As this clap behavior is not documented, tests have been added, see b735319
- There is one caveat:
clapfails to notice that an argument is provided twice.
|
@didier-wenzek Overall the changes look very nice, though I'm just wondering whether the Do we need to put some of the commands under a some subcommand like |
|
@didier-wenzek I think it would be useful if we make all of the binaries which can be access via symlinks also available via subcommands, but since there are a few tricker cases (e.g. c8y-firmware-plugin, c8y-remote-access-plugin), so here is the suggested structure (and the associated symlink equivalent in brackets).
Alternatively, if we could just do a flat structure and just place all of the binary names under one subcommand:
|
The second approach with |
reubenmiller
left a comment
There was a problem hiding this comment.
Just two minor points:
tedge-apt-pluginis missing undertedge run- Can we sort the subcommands under
tedge run? I don't mind havinghelpat the end, however the current order seems to be manually defined.
For some reasons I have to understand better,
Indeed, these sub-commands are listed here: https://github.com/thin-edge/thin-edge.io/blob/main/crates/core/tedge/src/cli/mod.rs#L52 Any order in mind? |
alphabetical is fine |
This is to exit with a status code of 1 and not 2 when the command line cannot be parsed: I will handle that case |
Bravo555
left a comment
There was a problem hiding this comment.
Nice improvement, I won't have to manually create dummy binary files for different components to do cargo run anymore!
That said, looking at tedge run --help there are some inconsistencies that could be fixed:
Run thin-edge services and plugins
Usage: tedge run [OPTIONS] <COMMAND>
Commands:
tedge-mapper tedge-mapper is the mapper that translates thin-edge.io data model to c8y/az data model.
tedge-agent tedge-agent interacts with a Cloud Mapper and one or more Software Plugins
c8y-firmware-plugin Thin-edge device firmware management for Cumulocity
tedge-watchdog tedge-watchdog checks the health of all the thin-edge.io components/services.
c8y-remote-access-plugin Thin-edge.io plugin for the Cumulocity IoT's Cloud Remote Access feature
tedge-write tee-like helper for writing to files which `tedge` user does not have write permissions to
help Print this message or the help of the given subcommand(s)
snip...
tedge-mappermentionsc8y/az, but notaws- the style is inconsistent (capitalization, if the sentence is terminated by a
.)
These descriptions are taken from package.description field of Cargo.toml of these crates, so they should either be fixed there, or we could provide the descriptions directly in code by adding doc comments to the Component enum variants; however I think updating Cargo.tomls would be preferable.
Doing this however would be best in another PR, so approving this one.
Addressed by 1bdac43 |
The following are now equivalent: - `tedge mapper c8y` - `tedge-mapper c8y` where `tedge-mapper` is a copy or a symlink of `tedge` The former `tedge` cli can be invoked as before: ``` $ tedge help CLI arguments that should be handled by all thin-edge components Usage: tedge [OPTIONS] <COMMAND> Commands: init Initialize Thin Edge cert Create and manage device certificate ... mapper Launch a cloud mapper agent Run the agent write Write standard input to a target file ... ``` Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
Since the introduction of common arguments, the header of `tedge help` was wrongly taken by clap from the `CommonArgs` doc comments (i.e. "CLI arguments that should be handled by all thin-edge components") Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
This allows running the tedge binary via `cargo run` without having to specify `--bin tedge`
tedge-apt-plugin specific treatment in tedge/main.rs was only for exiting with 1 and not 2 when the command line cannot be parsed. Signed-off-by: Didier Wenzek <didier.wenzek@free.fr>
1bdac43 to
c80b3d0
Compare
Proposed changes
Simplify the way
tedge-mapper,tedge-agentandtedge-writeare launched: it's no more mandatory to create symlinks totedgewith appropriate names.The following are now equivalent (for the mapper, but also the agent and all tedge services and plugins ):
tedge run tedge-mapper c8ytedge-mapper c8ywheretedge-mapperis a copy or a symlink oftedgeThe former
tedgecli can be invoked as before:Types of changes
Paste Link to the issue
#2696
Checklist
cargo fmtas mentioned in CODING_GUIDELINEScargo clippyas mentioned in CODING_GUIDELINESFurther comments
This PR supersedes #3311