Unable to see some build definitions listed on adding the widget

[msingh19]

Our team owns a number of build definitions, a few of them don't get listed in the list of build definitions shown in the widget. Any idea why that may be the case?

[msingh19]

It seems like the following call to get the definitions does not return all the definitions-
https://microsoft.visualstudio.com/e8efa521-db8e-4531-9cd8-6923807c7e83/_apis/build/definitions

We might need to modify the api call, to return all build definitions.

[sdavis3]

What specifically can you share that is different about the build definitions that are not showing? The API call I'm making is not passing in any filter parameters to limit the results, this all should be showing. Once a build definition is selected, of course, only successful builds will show code coverage, but I assume that's not your issue.

[msingh19]

So I just found out that there is a limit of 1000 build definitions that can be returned from the api call the widget makes:- https://microsoft.visualstudio.com/e8efa521-db8e-4531-9cd8-6923807c7e83/_apis/build/definitions

We might have to update the code to be able to somehow get hold of all the build defs in a loop or something. Is this something that you can address?

[msingh19]

more details on the calls that are needed:-

1. First call:- https://microsoft.visualstudio.com/guidfortheteamproject/_apis/build/definitions?type=Build&queryOrder=DefinitionNameAscending
2. Second call: https://microsoft.visualstudio.com/guidfortheteamproject/_apis/build/definitions?type=Build&queryOrder=DefinitionNameAscending&continuationToken=nameofthelastbuildfromthe firstcall

Basically the api takes in a continuationtoken which is the name of the last build the previous call to the api had returned

[sdavis3]

Understood. I will address this to support your use case. Thank you for the research.

While we're at it, since you have greater than 1,000 build definitions, how does the UI work for you when selecting a specific build definition from the drop down list?

[msingh19]

Thanks, appreciate the quick response.
Basically, currently the api call takes somewhere around 20-25seconds to complete. The drop down for the builds is blank till that happens. I generally wait for some time and then try selecting the builds.

Not saying that we need the following, but it will be great, maybe in future, to get a search based on some text. That will improve the user experience vastly, as well.

[msingh19]

Hi Shane, when do you think you can fix this issue?

[sdavis3]

I should have some time this evening (US time) to get this corrected, tested, and published.

[msingh19]

That'll be awesome, thanks Shane.

[sdavis3]

Looks like some things have changed with the SDK since I last updated this extension. Unfortunately, it's going to take me a little longer to get it updated.

[msingh19]

Sure, that’s fine. I will wait.

[msingh19]

Hi Shane, were you able to get time to check on this?

[sdavis3]

After an enormous amount of trial and error, the continuationToken does not appear to be completely supported in the BuildHttpClient 2.2 which is the version I'm forced to use inside of the widget. I can get it to recognize I'm making an attempt to to use it, but I can't see that it's returning the proper token for me to use on subsequent calls as I'm receiving a "Continuation token timestamp without query order is ambiguous" error. It's the timestamp value that I need, but it doesn't appear to be available in the return results from the .getDefinitions call.

I have the code written for when the client SDK is updated to support newer versions of the Azure DevOps REST APIs.

I've also sent out a message to the Azure DevOps team to get support on this since the docs are dated 2016. I suspect there are newer versions of the client available, but they are undocumented.

I'll keep this issue open until we get resolution.

[msingh19]

Thanks for checking on this Shane. As per my discussion with vso team, the continuation token was supposed to be the build definition name. I tried the url’s directly with that, and it worked. Is it the case, for you, that the SDK you are using does not support sending build definition name as the continuation token?

Also are you saying the latest SDK does not support the new azure DEV Ops api’s?

[msingh19]

Also, I may be able to help out with the azure DEV ops team. Maybe you can share the link/question that you asked them. I may be able to get that discuss taken forward quickly.

[sdavis3]

Correct...the API you used is a REST endpoint that is not available in the client SDK from within Azure DevOps. The client SDK docs for Build details are located at https://docs.microsoft.com/en-us/azure/devops/extend/reference/client/api/tfs/build/restclient/buildhttpclient2_2?view=vsts. It's a much smaller subset than what is available on the REST endpoint.

Here is the Twitter thread I sent to Buck Hodges: https://twitter.com/Shane_B_Davis/status/1087005571377758209

[msingh19]

Just a thought; searching by a name might be a workaround to deal with this issue. Now this might be a feature request rather than a bug. I wanted to check if that is a quick change on your side?
The getdefinitions call takes a ‘name’ parameter. I am hoping that might work in my case. Not sure how the UX will handle this change related to the searching by name.

[msingh19]

I’ll check on the question you sent to Buck.
Thanks for sharing the link.

[sdavis3]

That's a good idea...I'll investigate that and see what it looks like from a UX perspective.

[msingh19]

Great, thanks. Basically I would just paste the definition name and if found the widget will return the build definition.

[sdavis3]

I've just sent an email to Buck as well with more detailed information. Fingers crossed.

[msingh19]

Sure Shane; we you able to check on the suggestion I shared of searching based on the name? That might just work for us perfectly.

[msingh19]

Hi Shane, were you able to make any progress? Not sure if you got a reply from buck; maybe we should try the route where user can enter a build definition and the widget then searches based on that?

[sdavis3]

I did get a response that they found a bug in their publishing process and it should be rectified "soon". Thus, the docs are stagnate from 2016. In the meantime, I will take a look at an alternate UI, but I am travelling the next couple weeks, so it may take me a bit to get it resolved.

[msingh19]

Sure Shane; I might look at the code as well from my end.

[sdavis3]

That would be great. Pull requests are always appreciated :)