Describe the feature or problem you’d like to solve
I'd like to check if a specific secret exists w/o having to parse all the secrets in a repository. And I'd like to check if a specific deploy-key exists w/o having to parse all deploy-keys in a repository.
Specifically, I'm in the process of adding deploy-keys and corresponding secrets to dozens and dozens of repositories. Some I've already added, most I haven't.
I don't want to trip on already existing deploy-keys/secrets, and while I could try to keep a list of what I've done, it will never be as accurate as the actual information from the horse's mouth (🐴 👄 ).
Proposed solution
Whether that's via supporting an extra argument to gh {secret|repo deploy-key} list or whether that's via a new verb gh {secret|repo deploy-key} {info/view} ..., something that enables me to ask "does a given thing exist" would be immensely helpful.
While I don't really want it, consistent access to json output would be better than what I have today:
gh repo deploy-key list currently takes no flags and has no output formats, which means that parsing its output will almost certainly be not remotely fun. The date format in the last "column" is not regular (some times are relative, e.g. 16h, and most are probably absolute). The second column can include spaces in "key" "names", which means that isn't the way to parse it. It's possible one could be really foolish and include read-write or read-only in the key name. It's probably technically possible to work from the right backwards, but again, see the relative date bit for the pain there. When the output is sent to a pipe, the columns don't even align, so, one can't even rely on the column position from the first "row" for the third or fourth "columns" in order to try to consume things.
Currently, gh repo view supports -q, --json ..., and -t ...
Additional context
Add any other context like screenshots or mockups are helpful, if applicable.
Describe the feature or problem you’d like to solve
I'd like to check if a specific secret exists w/o having to parse all the secrets in a repository. And I'd like to check if a specific deploy-key exists w/o having to parse all deploy-keys in a repository.
Specifically, I'm in the process of adding deploy-keys and corresponding secrets to dozens and dozens of repositories. Some I've already added, most I haven't.
I don't want to trip on already existing deploy-keys/secrets, and while I could try to keep a list of what I've done, it will never be as accurate as the actual information from the horse's mouth (🐴 👄 ).
Proposed solution
Whether that's via supporting an extra argument to
gh {secret|repo deploy-key} listor whether that's via a new verbgh {secret|repo deploy-key} {info/view} ..., something that enables me to ask "does a given thing exist" would be immensely helpful.While I don't really want it, consistent access to json output would be better than what I have today:
gh repo deploy-key listcurrently takes no flags and has no output formats, which means that parsing its output will almost certainly be not remotely fun. The date format in the last "column" is not regular (some times are relative, e.g.16h, and most are probably absolute). The secondcolumncan include spaces in "key" "names", which means that isn't the way to parse it. It's possible one could be really foolish and includeread-writeorread-onlyin the key name. It's probably technically possible to work from the right backwards, but again, see the relative date bit for the pain there. When the output is sent to a pipe, the columns don't even align, so, one can't even rely on the column position from the first "row" for the third or fourth "columns" in order to try to consume things.Currently,
gh repo viewsupports-q,--json ..., and-t ...Additional context
Add any other context like screenshots or mockups are helpful, if applicable.