Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Implementing IClientCommandProvider.GetClientCommandPreview
-
// Summary: // Returns a string containing the command to be passed to the tool. // // Returns: // String containing the command to be passed to the tool. // // Remarks: // This will typically be displayed to the user, so passwords should be obscured. string GetClientCommandPreview();
I'm not sure how to implement this method in any provider without the arguments
(string commandName, string arguments)
which are provided toExecuteClientCommand
. Has this method been implemented in any of the existing source control providers yet? Right now it seems like a placeholder in the API for something they plan to implement later.Product: BuildMaster
Version: 4.5.7
-
This is implemented, but is only used in the action editor for the Execute Client Command action. Not too many providers actually implement this, since the whole client command provider idea never really took off, but I know offhand that the SourceGear Vault extension does implement it:
https://github.com/Inedo/bmx-sourcegear/blob/master/VaultProvider.cs#L421
That extension is a little old, but I think the basic idea is that that method returns the exact arguments that would be passed to the client (with passwords/other sensitive info obscured). Again, it's only used by the editor so you can just return an empty string and it will work fine. We'll try to get the SDK documentation updated soon.
-
Even there it doesn't seem to be actually previewing the command that's being run, just giving the other arguments it's passing the the executable along with yours.
I can understand why IClientCommandProvider didn't take off, it's much easier to use built-in recipes, but the interface really needs to be looked at since the current source control provider implementations don't allow DVCSs to do all of the push/pull/branch/merge things they're known for which really limits available workflows.
I'm trying to implement it for Mercurial right now and there are quite a few backflips necessary to get it working.
-
Sorry, this question somehow got marked as resolved, but it doesn't look like you ever got a response. If you'd like, you can email us at support at inedo.com with details about what you are trying to do, and we can try to give you some more specific help/ideas.