Some Bugs in the new Client REST api

[LividInteractive]

Hey Plastic SCM team I've been playing around with and trying to build an automation system around the new REST client.  (https://www.plasticscm.com/documentation/restapi/plastic-scm-version-control-rest-api-guide.shtml#Introduction)

 

I've found a couple of bugs so far.

 

In the API docs for the Switch workspace to a different branch/label/changeset  endpoint  (POST /api/v1/wkspaces/:wkname/switch) 

 

it lists the parameters as originType:string and origin:string   however these throw an exception and it seems the api is actually expecting  objectType:string and object:string,  that seems like a bug in the implementation as  originType ect is accepted correctly

on other endpoints.

 

The other issue I'm having is with the Check in endpoints.   The POST call to do the check in seems to return correctly with a response like:

 

{
"status": "Checkin operation starting...",
"totalSize": 0,
"transferredSize": 0
}

 

However the check in doesn't ever happen.  And if you try to query the status with the Retrieve checkin status  endpoint it always returns:

{
  "status": "Failed",
  "message": "There are no changes in the workspace g:\\Livid\\RenderWorkSpace"
} 

Even if there are pending changes. 

And even if I manually kick off the checkin from the Plastic GUI and am watching the progress bar go along, concurently calling the checkin status endpoint will still return the same  Failed/No changes message.

[ralph_on_me]

I think I'm hitting this bug too.  I've been converting the C# classes into an ASP.NET webform, but on switching the workspace I'm getting errors as well.

[mig]

Hi LividInteractive,

 

Could you please share what are the checkin POST request contents? Have in mind that calling the checkin POST endpoint will launch a basic checkin operation in your workspace root. This will only consider controlled changes (i.e. changes explicitly notified to plastic through any of its UIs). For instance, locally changed files will not be detected as changes to be checked in, whereas checked out files will. You can check this using the GET /api/v1/wkspaces/:wkname/changes?types=controlledchanged endpoint.

 

You can also manually specified the paths to be checked in when you call the checkin POST endpoint. This JSON object will select /src/foo.c, /src/bar/baz.c and anything under /doc to be checked in:

{
  "paths": [
    "src/foo.c",
    "src/bar/baz.c",
    "doc"
  ],
  "comment": "Upgrade core engine",
  "recurse": true
}

Finally, regarding the lack of sync between the Plastic SCM GUI and the REST API: that functionality is not available at the moment. Each client is currently independent of other instances, so kicking off a checkin in the GUI will not update the REST API status. However, if you launch a checkin while the GUI has locked the workspace (e.g. during update or checkin) the checkin GET endpoint will return a Failed status revealing that the workspace is locked.

 

I hope this will help you finding a solution to the issue! Please don't hesitate to share more details about your situation if you're still in trouble.

 

Regards,

Miguel

[ralph_on_me]

Miguel, are you sure /api/v1/wkspaces/:wkname/changes?types=controlledchanged works?  It only returns 

<Error>

<Message>An error has occurred.</Message>

</Error>

if I try it.

Also LivingInteractive correctly diagnosed the incorrect object name.  The documentation or the API is incorrect.