Jump to content
DarkCamper

Improved "cm.exe" command output

Recommended Posts

Hi,

I'm currently developing an addin for Cakebuild to allow cake scripts to interact with Plastic (there are currently addins for Git, VSTS, Subversion and some other VCS), but I'm having a hard time dealing with the output of "cm". I've already implemented support for a few commands and the output behavior seems very uneven across different commands:

  • Some commands accept the --xml argument
  • Other commands allow --machinereadable + --fieldseparator
  • Yet other commands only allow --format (or --errorformat)
  • When using --errorformat + --ignorefailed with "add" all ignored errors are not formatted (either with --format or --errorformat). I don't know if they're not considered as errors internally but they show up in the output with a localized human readable string, and that's not very convenient for automated parsing.
  • --silent is not really silent (at least with "add")

Is there's some kind of option to get a homogeneus output that I'm not aware of?

I've also thought of using plasticapi.exe, but it seems to be lacking many things that the command line tool allows to do (and having to open a REST service when there's a complete cli tool seems a bit awkward to me).

I know you guys are trying really hard to have a strong presence in the DevOps scene (things like the mergebots are actually really cool and we plan to give them a try!) and improving the cli behaviour would make it easier for people to use plasticscm in their CI pipelines, regardless of the CI system or bussines process they might have chosen.

Kind regards,

Rubén

 

Share this post


Link to post
Share on other sites

Hi Rubén,


Thanks for reaching out and for your heads up on the inconsistency of the command line.

We are aware of the weak points in cm. The main reason is that we (and I'm the one to blame, so I should say "I") didn't really *design* the command line but mostly just added stuff as needed. In the last few years we started being really focused on really designing the whole thing, really thinking on the solution as a whole, you know, doing real product design. We now try to come up with consistent behaviors across the entire system. But the command line is still work in progress.

So, any feedback on what you expect to make it better for automation will not only be welcome but it will serve as a starting point for an improvement. And since we are doing more than 1 release a week, you can expect updates coming soon.

Now, onto the specifics: you can check our "CmdRunner" for more info on automation. https://www.plasticscm.com/documentation/cmdrunner/plastic-scm-version-control-cmdrunner-guide. While the cm can really be improved, it doesn't mean it is not fully tested. In fact, command line automation is a cornerstone of our testing system.
Every single task that enters into a release goes through hours of unit testing, command line testing, and GUI testing. Command line testing (or smoke tests as we call them internally) are tests based on PNUnit (our extension to NUnit) that automate Plastic by running cm commands on Windows, Linux and MacOS. 800+ tests overall running on several combinations. And CmdRunner is what we use to run all these commands on a daily basis. It doesn't mean is perfect, but it is really what we use daily to write more tests (although I must say in the last years we focused more on NUnits than CmdRunner tests).

Finally, the REST API comes as a complement of CmdRunner. The latter is C# based, and since we can't expect everyone to use the same framework we use, we came up with a REST API. The other alternative would be some sort of universal C library so that any language could wrap it (anything else wouldn't be really doable since C is still the most portable and linkable option). But since we don't write C but C# 99% of the times, the C path wasn't good. But invoking REST is something any language can do, so we decided to go for a REST API, even to invoke local actions like an update or a checkin.

So, if there's anything specific you miss in the REST API, please let us know and we'll add it.

Thanks!

pablo
 

Share this post


Link to post
Share on other sites

Hi Pablo, thanks for your quick response.

On 10/7/2018 at 9:42 PM, psantosl said:

We are aware of the weak points in cm. The main reason is that we (and I'm the one to blame, so I should say "I") didn't really *design* the command line but mostly just added stuff as needed. In the last few years we started being really focused on really designing the whole thing, really thinking on the solution as a whole, you know, doing real product design. We now try to come up with consistent behaviors across the entire system. But the command line is still work in progress.

Yeah, I know. It's really common for growing projects to become a bit of a mess unless you spend some serious time designing for consistency. And plastic has grown a lot.

 

On 10/7/2018 at 9:42 PM, psantosl said:

Now, onto the specifics: you can check our "CmdRunner" for more info on automation. https://www.plasticscm.com/documentation/cmdrunner/plastic-scm-version-control-cmdrunner-guide. While the cm can really be improved, it doesn't mean it is not fully tested. In fact, command line automation is a cornerstone of our testing system.
Every single task that enters into a release goes through hours of unit testing, command line testing, and GUI testing. Command line testing (or smoke tests as we call them internally) are tests based on PNUnit (our extension to NUnit) that automate Plastic by running cm commands on Windows, Linux and MacOS. 800+ tests overall running on several combinations. And CmdRunner is what we use to run all these commands on a daily basis. It doesn't mean is perfect, but it is really what we use daily to write more tests (although I must say in the last years we focused more on NUnits than CmdRunner tests).

I know CmdRunner but it doesn't really help that much by itself (it's a nice wrapper to call 'cm' and retrieve the raw results, but the painful task of parsing all the different formats is still there). I never implied (sorry if I did it by mistake) that the CLI tool is not tested, only that using it for automation is sometimes a cumbersome process due to inconsistencies.

 

On 10/7/2018 at 9:42 PM, psantosl said:

Finally, the REST API comes as a complement of CmdRunner. The latter is C# based, and since we can't expect everyone to use the same framework we use, we came up with a REST API. The other alternative would be some sort of universal C library so that any language could wrap it (anything else wouldn't be really doable since C is still the most portable and linkable option). But since we don't write C but C# 99% of the times, the C path wasn't good. But invoking REST is something any language can do, so we decided to go for a REST API, even to invoke local actions like an update or a checkin.

I agree with you, a REST API is simply the best when offering a universal service.

And now my letter to Santa (or to the Three Wise Men, your choice) with some suggestions/wishes:

  • Please (please!) improve the documentation, both online and the help text of the CLI. Your tools have tons of hidden options and parameters that allow you to do really useful stuff! Even with well-known arguments sometimes you don't know what values can they take or what will they do when you use then. And when using "--machinereadable" I haven't been able to find information about what does each field mean, what values can they have... When reading the docs it's easy to find info about simple tasks but when things get a bit more complicated (just a bit, nothing really weird) these forums are the only realistic choice we have. You guys do a great work answering all the posts, but I think that many times all that information should've already been available in the docs. Or somewhere where google (whose tentacles reach everywhere) could index it.
  • For the CLI tool. How about adding a "--json" argument to all commands that makes it output a json string with all the results of the execution? I know some commands have a "--xml" option (and I wouldn't mind if you added --xml instead of --json to your commands) but maybe using json you could share some code with the REST service ?
  • For the REST API I think that the most important (at least for me) missing features would be to be able to do merges (with all the special stuff that happens when merging such as file/dir conflict resolution) and shelves.

And that's all. Hope it didn't sound much like a rant, I really love Plastic (I suffered subversion and VSS before, uuuugh).

 

 

Share this post


Link to post
Share on other sites

Thanks Rubén,

I just wanted to follow up with this:

  • In the last versions since you wrote this we released a few command line improvements trying to make the whole thing better. Small tweaks here and there but the goal is to really make a big change in a few weeks. Check 7.0.16.2828 for instance.
  • We reviewed some on the CLI docu. Still work to do.
  • The plan is to continue expanding the REST API.

We are in the middle of a few things right now that keep us certainly busy, but we are really committed to make all these happen.

Some of the big things we are on:

  • Tons of improvements to the macOS GUI. We always get heads up from users telling it is not on par with Windows.
  • Multi-process server for Enterprise setups. This is a big effort and we need it to circumvent some issues in Mono and as the basis for the next Plastic Cloud we are working on. (I could talk about this for hours but I will just keep it short).
  • New Unity Plugin. Unity teams are key for us. We are working on a big new plugin (where, small and easy, but big effort).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...