add a `--max-responses` global field

[georgettica]

sometimes, our service is a bit bogged with details and I just need the header / the first few items.

 pd incident:list --team ${MYTEAM}
Getting incidents 1/19 👍, 0/19 👎... ⡿

could we add this

pd incident:list --team ${MYTEAM} --max-responses 20
Getting incidents 0/1 👍, 0/1 👎... ⡿

[martindstone]

That sounds like a good idea, I'll do it

[georgettica]

any update?

[martindstone]

Hi @georgettica I have not had a chance to do this yet, blame my day job! But I should be able to get to it pretty soon, say within the next week or so...

[georgettica]

I won't blame it, but I am glad to see you know it's there and have it somewhere on your roadmap

[martindstone]

hey @georgettica i finally got it implemented. Could you update to the RC (pd update rc to use the RC, pd update stable to go back to the stable version) and check it out? What I did was I added a --limit flag to all the list commands and to rest fetch. Let me know what you think.... thanks...

[georgettica]

I logged of, but as I am so excited for this I am logging in to check this!

[georgettica]

yes! this is great :)

but I was not able to fully test this as the endpoint by default now cuts at 25 responses. but if I set the --limit to be high it happens

[georgettica]

as noted here https://github.com/martindstone/pagerduty-cli/blob/bf1eaf75471b1582cbe3aa79edfc0feee10b0fc4/src/pd.ts#L362

[georgettica]

could I also get the --all field so I can choose when to limit it off and when to run wild?

most times I want this limit, but sometimes the --all is good for scraping

[georgettica]

and once mentioned before, pd update doesn't work on npm install -g pagerduty-cli

[martindstone]

Oh yikes. That's a bug. Sorry, figuring it out now...

[martindstone]

I found the problem, ugh sorry, my logic for checking whether we fetched past the fetch limit was slightly wrong... i am pushing 0.1.2 now... wish there was a way to mark a version as "bad"

[martindstone]

Ok it's pushed. Can you try with 0.1.2 and let me know? Sorry for the screw up

[georgettica]

Sure, will do that tomorrow morning and let you know

[georgettica]

yup, works as expected. without --limit it shows all with --limit it shows what I wanted.

now for the next milestone we might allow --filter (count matching results)

[martindstone]

So I would really like to be able to do that but sadly everything in --filter happens after the data is fetched... that's why I disable it when --limit is given, because the results in this case could lead the user to believe things that are not true... and the filtering options that you can give to the REST API are very few... so the best way to try to filter and limit will be to pass --limit to rest:fetch and use other endpoint params as documented in the PD REST API doc to try and get what you want.

Regarding the update not working, I added the note about npm installs not being updatable more prominently to the doc. For anything more than that I will have to either change oclif/plugin-update or stop using it and make something myself which I think is longer term. I will continue to think about that... In the meantime i will plan to close this issue once i promote 0.1.2 to stable which should be in a few days...

Thanks!

[georgettica]

If this can also be noted inside the upgrade command itself that would be super nice

And if we are talking about upgrades, I see there is a new version available in the CLI, but you mentioned it's not stable and shouldn't be upgraded automatically

[martindstone]

Yeah i am going to promote 0.1.3 to stable soon, the most risky stuff in there is frankly what I did for this issue with the --limit flag; otherwise everything should be fine... the only changes from 0.1.2 to 0.1.3 are some added commands for working with tags...

[martindstone]

Closing this as fixed...