You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently made a change to improve the performance of stack ls - but as part of that also changed the correctness of stack ls -a to not report all stacks if there are more than 300. A warning is issued when there are more - but it does not indicate what users can do to actually get all stacks.
We should:
Provide a way to actually get all stacks
Possibly make that the default again for stack ls -a
If we do continue to limit by default, include enough information in warning for users to actually get all stacks (or limit query by project If necessary).
I would recommend adding the 300 Max to the documentation so users will not rely on it (as we did) with their automation tools.
if i use a tag filter with the CLI will it still hide results? Cause i still see the warning. Where as if i use the project filter i don't
The text was updated successfully, but these errors were encountered:
I did some tests and indeed filtering by tag will hide some results even if result set size is < 300 . My guess is that all stacks are returned and then filtered by tag - which hits the Max 300 limit.
We recently made a change to improve the performance of
stack ls
- but as part of that also changed the correctness ofstack ls -a
to not report all stacks if there are more than 300. A warning is issued when there are more - but it does not indicate what users can do to actually get all stacks.We should:
stack ls -a
Cross ref slack discussion.
Other notes:
The text was updated successfully, but these errors were encountered: