When configuring the AzDos widget I can see the default Space, which is all we have, and the environments but the projects never load.
The chrome DevTools console shows this error:
Cannot query datasource with response size greater than 2 MB
Since we have more than 600 projects in OD I am not surprised we break this limit.
I found only one result when I searched for this error. This in turn points to newly implemented pagination.
What about getting a list of the groups and then selecting the projects associated with the group
or add a text field for allowing manual entry of the name which can then be confirmed by a rest call.
First of all, welcome to the Octopus forums!
Thanks for reaching out. I’m going to speak to some colleagues and dig in and see if we can’t find a solution for you.
Please feel free to let me know in the meantime if you have any questions or concerns.
After investigations today, we’ve flagged a new issue with priority for our engineering team to review/action over the next week.
You can track this issue here to be notified when a fix is available.
Sorry for the inconvenience and thanks for bringing this to our attention.
Thanks for the quick responses.
I had a look at what I get when I call the OD api directly for all projects and the file is nearly 4mb.
We do use the Description field pretty heavily to link to the related build and code repository, as a concise changelog for the process (since there is no history functionality), and for links to the deployed application for verification purposes. Each one isn’t super big when rendered on the page, but since it includes quite a few links it adds up quickly when you get up to the numbers of projects that we have.
We really wouldn’t want to remove these references as they greatly simplify day to day work. Having to tie the whole chain together some other way would be cumbersome and probably mean that it would get neglected and quickly outdated. This functionality really makes Octopus Deploy our activity hub and is very valuable to us.
Thanks for letting us know about the descriptions. That helps to give us more context, and yes, that workaround is not ideal.
This is an unfortunate limitation of us using these
/all endpoints for the extension, which is not great, considering we only need the Id and Name in those dropdown fields
We’re going to move ahead with the project filter idea you mentioned and allow a keyword search for selecting projects. The project-group idea was explored today, but it runs into the same problem if you have a large number of projects in a single group with large descriptions, so we’ll move away from the
/projects/all endpoint and allow filtering projects by name to help unblock this problem.
We should have something available this week.
Hi again Heidi,
We ended up going with the Project Group filter approach (as we ran into a lot of issues trying to get a project keyword/filter working, due to some old dependencies our extension code is using).
Hopefully the response from projects within a project group are under the 2MB limit for you, and if not, creating smaller project groups may be a workaround for you.
We hope this helps. Please let me know how you go.
Thanks Mark! This solution should work out fine for us. We have a lot of project groups and none of them have large numbers of projects in them - yet at least.
Unfortunately, the guy who would install the updated widget on our Azure DevOps servers is on holiday so it will be a few weeks before I can test this as I will be on holiday soon myself.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.