NEW VSTS Work Item Actions (beta quality)

Yes, will do that.

Hi Vincent,

Just to report that the “URI too long” issue was related to a large number of work items being returned. I believe this is something you’re going to look at so at least FinalBuilder reports a better error to the log file. Damn Microsoft generic errors!

In the TFS Query I could use a query with the format ddmmyyyy, but in VSTS Query this now returns a 400 error. Changing it to a SQL Date format of yyyy-mm-dd fixed the issue. This isn’t a FinalBuilder issue, but helpful to those migrating to VSTS.

Finally, when using the <b>VSTS Query Work Items > Behaviour > Write formatted output to a variable</b>, as follows:

[code]<li>{System.Title} [{System.WorkItemType}-{System.Id}]</li>[/code]

FinalBuilder is failing to find the Id. I’ve tried with and without System. Any thoughts on how to get the Id out?

Regards,
Heath

Hi Heath

Please try this build : http://downloads.finalbuilder.com/d...0_2432.exe

I added a check if the URI for fetching the workitems (it involves 2 queries, first on gets the id's, second one passes the id's on the query string) is > 1900 chars. I also added the System.Id field, that is actually returned outside the fields array so needed some finessing.

I am trying to run the Team Foundation Query Work Items action and receive this message:

An unexpected error occured :
Could not load file or assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have installed Visual Studio 2017 15.7.4 and FB 8.0.0.2432

Sorry, I completely missed the VSTS specific task for this action. I have got it working. Thank you!

Posted By Vincent Parrett on 28 Jun 2018 05:39 PM

Hi Heath

Please try this build : http://downloads.finalbuilder.com/d...0_2432.exe

I added a check if the URI for fetching the workitems (it involves 2 queries, first on gets the id's, second one passes the id's on the query string) is > 1900 chars. I also added the System.Id field, that is actually returned outside the fields array so needed some finessing.

Hi Vincent,

I can confirm that build 2432 is working like a charm and the Id is now retrievable.

Have you any plans to extend your VSTS actions to include getting/enumerating TFS builds and apply tags?

Regards,
Heath

I have been finding that even though I provide a value for the 'Project name' field, I still need to add WHERE System.TeamProject='MYPROJECT' or else other team projects' work items are returned.

Also, when trying to reference a custom Boolean field (WHERE MyScrum.QAComplete='True') w/ and w/o brackets [MyScrum.QAComplete], I get:

Error executing request : Response status code does not indicate success: 400 (Bad Request).

However, specifying MyScrum.QAComplete in 'Log values of these fields' I am able to return them.

Posted By Heath on 04 Jul 2018 05:25 AM

Hi Vincent,

I can confirm that build 2432 is working like a charm and the Id is now retrievable.

Have you any plans to extend your VSTS actions to include getting/enumerating TFS builds and apply tags?

We can certainly look into that. We're currently focusing on providing the same level of functionality as we had before with older tfsclient based actions. Let us know what you need.

Posted By skdhc on 05 Jul 2018 09:42 AM

I have been finding that even though I provide a value for the 'Project name' field, I still need to add WHERE System.TeamProject='MYPROJECT' or else other team projects' work items are returned.

There are lots of issues I have with the vsts rest api. This shouldn't happen, since we are specifying the project as part of the request uri, however that doesn't seem to work as expected/advertised :

string resource = String.IsNullOrEmpty(projectName) ? $"_apis/wit/wiql?api-version={apiVersion}" : $"{projectName}/_apis/wit/wiql?api-version={apiVersion}";

Also, when trying to reference a custom Boolean field (WHERE MyScrum.QAComplete='True') w/ and w/o brackets [MyScrum.QAComplete], I get:

Error executing request : Response status code does not indicate success: 400 (Bad Request).

However, specifying MyScrum.QAComplete in 'Log values of these fields' I am able to return them.

This might be a case sensitivity issue, try true rather than True. The VSTS rest api is infuriating when things go wrong, as all you get is a 400 error and no response body with an explanation, makes it very difficult to figure out what you did wrong. I'll have a play with this today, first have to figure out how to add custom fields (I'm not a tfs user!) ;)

Hi Vincent,

I believe the project name is need in the VSTS Query because any project based URI can perform a query on other projects within the collection. Just a theory.

Regards,
Heath

I found out the correct syntax for Boolean fields after trial and error - do not include quotes around the value. I received results after specifying MyScrum.QAComplete=True

Issue with the VSTS Edit Work Item(s) action - in the second Query it adds the VSTS server where the Team Project should be.

Using credentials from Options.
Querying for work items…
Work item query : SELECT * FROM WorkItems
WHERE System.TeamProject=‘MyProject’
AND System.State<>‘Done’
AND System.Id=‘80’
AND MyScrum.QAComplete=True
AND (System.WorkItemType=‘Bug’ OR System.WorkItemType=‘Product Backlog Item’)
Querying resource : https://mysite.visualstudio.com/MyProject/_apis/wit/wiql?api-version=3.0
Found 1 work item(s), processing…
Editing work item id:80 “Product Backlog Item 2”
Applying field values…
Querying resource : https://mysite.visualstudio.com/https://mysite.visualstudio.com/_apis/wit/workItems/80?api-version=3.0
Error updating action : Response status code does not indicate success: 400 (Bad Request).

The Querying resource log entry is incorrect, it’s not actually doing that (I have fixed that for the next update).

The problem will be in one of the fields you are setting, unfortunately Microsoft have made it impossible to tell which (other than by trial and error) as all they return is a 400 badrequest response with no response body explaining what they didn’t like about it.