Add a dry-run flag to commands

[AliabbasMerchant]

Describe the feature or problem you’d like to solve

CLI is used for creating significant changes(issues, PRs, comments) in various repositories.
This may lead to inadvertent/unintended permanent changes in repositories and organisations.
Example: Inadvertently creating test PRs/Issues while testing.

Proposed solution

Either:

1. Add a --dryrun flag to commands
   OR
2. Confirm before making significant changes (Like how most linux package managers do)
   "Do you want to make these changes? (y/n)"
   And a -y flag, to skip this prompt

How will it benefit CLI and its users?

Although it may add an extra prompt (which can be skipped via the -y flag), this may add a level of security/sureity as to what the intended action is, and what is occurring.

Additional context

A few of the recent fake/test PRs/Issues/Comments we have received may have been inadvertent
(Happened with me twice 😓 Thankfully, was able to convert them into something useful)

This would be a potentially huge change, and would require lots of investment in terms of time

[probablycorey]

I don't think we would want to add this to the non-interactive commands because we want the default behavior of those to be scriptable. For creating PRs and issues interactively, we have a "What's next" portion at the end.

@AliabbasMerchant, were you thinking that we'd want an extra stage after the "What's next section"?

[AliabbasMerchant]

were you thinking that we'd want an extra stage after the "What's next section"?

No. I think that is perfect and sufficient

I was referring to the non-interactive commands.
But since you mentioned that their default behaviour should be scriptable, I agree that adding the confirmation prompt would defeat that purpose

A --dryrun flag could be considered, but then again, the interactive way(which already has the confirmation prompt) should be the one preferred and used for non-scripting purposes, so...

[probablycorey]

@billygriffin what do you think about adding the --dryrun flag to some of the non-interactive commands that have actions that can't be undone? I like the idea in theory, but I'm not sure if it will do much because I can't think of any good output that it would give us.

[AliabbasMerchant]

#1330 is a good replacement for this

[GMNGeoffrey]

I'd like to suggest re-opening this. In particular when testing out scripts it is very useful to see exactly what a script would do without actually affecting state. For example gh pr create --dry-run would print the PR title and description back to confirm it worked as intended.

[mislav]

I'm interested in a dry-run flag as well! Hub, for example, has the --noop flag which I often found invaluable. 👍

[omBratteng]

Quite interested in this was well.
I'd like to create me some aliases, but testing them out at first, so I can check if the output is what I expected.

[sethfri]

Would love a dry-run flag as well for the testing considerations mentioned above. For example, I just wrote a script that looped through a bunch of PRs and retargeted their base branches. It would have been good to be able to dry run the gh commands in the script to make sure it was going to do what I intended

[samcoe]

Thanks for all the discussion here. We have decided that we are not going to make an application wide dry-run flag due to the amount of work that it would require. We are very much in favor of adding dry-run flags to targeted commands, for example I am currently working on one for extension upgrade #5098. In order to track that work more efficiently we think new issues for individual commands would be best so I am going to close this one. Please feel free to open up issues for commands that you feel would benefit from a dry-run flag.