Repository navigation
Add a dry-run flag to commands #1145
Description
Activity
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"?
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 purposeA
--dryrunflag 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...@billygriffin what do you think about adding the
--dryrunflag 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.#1330 is a good replacement for this
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-runwould print the PR title and description back to confirm it worked as intended.Reacted by Rahul Kumar, Raine Virta, Dane Podzkiewitz, Anton Rymkus, Seth Friedman, dugg molidor, Roman Gardukevich, Luciano Lima, Ivan Peshev, Saeed Seyfi and 4 moreI'm interested in a dry-run flag as well! Hub, for example, has the
--noopflag which I often found invaluable. 👍Reacted by Raine Virta and Alex OstrovskyQuite 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.Reacted by Mislav Marohnić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
ghcommands in the script to make sure it was going to do what I intendedReacted by Paul EusticeThanks for all the discussion here. We have decided that we are not going to make an application wide
dry-runflag due to the amount of work that it would require. We are very much in favor of addingdry-runflags to targeted commands, for example I am currently working on one forextension 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 adry-runflag.Reacted by Aliabbas MerchantReacted by Geoffrey Martin-Noble, Luciano Lima, nhooyr, Younghoon YUN, 4evy, Gwenn Le Bihan, Alexandros Sapranidis, Simon Blixenkrone, karunacybozu, offsetcyan and 6 more
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:
--dryrunflag to commandsOR
"Do you want to make these changes? (y/n)"
And a
-yflag, to skip this promptHow will it benefit CLI and its users?
Although it may add an extra prompt (which can be skipped via the
-yflag), 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