getProjects limited by default - increase it

[ilanramos]

Hi there,

I have a problem with my organization about an extension "Trigger Build Task" on which I cannot link my Team Project with its id.

On TfsRestService/index.ts line 541 there is a case that if Team Project inserted is not the actual ID it gets the guid value via API.

Looking all the way up till it gets to azure-devops-node-api/api/CoreApi.ts, on line 765 there is a reference that is used on the project above, one of the parameters accepted is "top", which leads me to my problem: in my organization we have a little bit more than a 100 projects (the default value for Microsoft list of project first page), as I have seen on other issues posted in here, there are more organizations with this problem.

So I am writing this issue, to check about the possibility of increasing the limit of projects listed to a larger number, which would solve all problems in many orgs, not only in mine. In my org we had to get all guids manually and insert it, but it would be a nice fix to next pipes if this number is increased so we would not necessarily search for it.

Is it in your radar to increase the top parameter? Because the number of projects in our organization will probably keep increasing.

Thanks in advance.

[huserben]

Hi @ilanramos

I see that this is a bit cumbersome if you have many projects.

Currently I have no plans on changing anything with the top parameter, as for me it's even hard to test (e.g. does the REST API even support more than "x"? Or is a loop needed to fetch all the projects using top & skip parameters?)

I'm not sure if a "proper" intergration makes sense by allowing to specify the top value as part of the tasks. Hardcoding it to any bigger number might also not be ideal. What I could think about is to check for an environment variable that is read and used as top parameter if it's set (and otherwise use the default). That way the behaviour of the task would not need to change (so all existing things for sure will work as is) and you could try if it solves your problem.

Currently I have no plans to immediately create a new version as I lack time, but I could add the environment variable whenver the next one is available and could let you know here.

Would that work for you?

[ilanramos]

Hi @huserben

First of all, thanks for the gentle response. I perfectly understand your concern, but let me try to add some more data, maybe we can get to someplace new.

About the REST API supporting "x", we are limited by Microsoft to have the maximum of 300 projects per organization, so top would necessarily be 300, since Microsoft limited it. (Source: https://docs.microsoft.com/en-us/azure/devops/organizations/settings/work/object-limits?view=azure-devops)

But if instead you choose not to hardcode it, I will perfectly understand and appreciate the effort you took by understanding my scenario. Despite being easier to have it automatically on code, if that is not possible, it would be really nice to have an environment variable to set it for future usage.

I really appreciate the support and attention, thanks!

[huserben]

I was not aware by the limit of 300 - I assumed it's limitless :-) So I think I can change top to 300 and perhaps allow the environment variable override (as a bit of a "hidden feature", just in case someone uses an Azure DevOps Server Version that has more than those 300).

Thanks for bringing this to my attention, it's really appreciated.

So moving forward I think I'll have some time in the coming days and a few open issues that I can bundle to a new release. Hopefully I can have a new version for you to verify by next week. If so I'd be glad if you could double-check it as I don't have an org with 100+ projects.

Would that work for you, also from a timeline perspective?

I would update you in this thread as soon as there would be any news.

[ilanramos]

I understand you, firstly I also thought it was limitless

That's a great idea, it would really happy a lot on our situation. I am the one who must be thankful, since you're actually updating it.

Of course I will double check it and confirm that everything went well, can you please keep me informed about any update? I will check as soon as possible and give you the good news. It would work perfectly from a timeline perspective as well, I will be waiting.

Thanks a lot for all the help and understanding! I will be waiting for any update.

[huserben]

Hi @ilanramos

I'm in the process of updating the tasks and it includes the changes for the getProjects calls. So I'd be glad if you could try this out in the latest version (triggerbuild task v 4.1.0, cancel/wait task v 3.1.0 - which ever you use :-)) as soon as it's available.

Thank you for your assistance.

[ilanramos]

Hey, @huserben, sorry for the long time, we have passed through some holidays in here.

Anyway, just to bring you some news, we have updated our pipelines, as soon as our team run any of it, I will update you, hopefully everything will be okay.

Thanks a lot for all the help!

[ilanramos]

Hi @huserben, great news!

Everything worked perfectly well, so once again thanks a lot for helping us out!

[huserben]

Glad to hear.

Please feel free to open up another issue in case you have an idea for improvement, found a problem or have a question in general.