Repository navigation
secret update #6327
Description
Activity
This makes perfect sense to me, thanks for the suggestion. I assume the API supports this operation (but whoever takes this on should confirm that before starting development).
Hi, I checked the REST API and found that there's no dedicated API for updating secrets. Only
PUT /orgs/ORG/{actions,codespaces}/secrets/SECRET_NAMEis exposed to create or update the secret. Thevisibilityis required. And ifvisibility = selected, theselected_repository_idsis required.Proposed solution
To maintain the selected repos visibility of existing secrets, with the current REST API:
Change the default value of
--visibilityto"". If--visibilityand--reposare emptyGETthe secret- If not found, set
visibility = private - if found, maintain
visibility- if
visibility = selected, maintainrepos
- if
- If not found, set
PUTthe secret withvisibilityandrepos
There's no changes if
--visibilityor--reposare not empty.A few things I'm not sure about this solution:
- Can we assign different default value that not belong to the enum flag?
- We might need to get multiple pages of
reposif the selected repos count is big.
What do you think?
Hi! Here I have an additional use case to consider for
secret update: changing the secret visibility without modifying the secret value. E.g: adding a new repository for a secret withvisibility = selectedwithout providing again the actual secret value.However, as @nsmag says, the API doesn't seem to explicitly support this either... If we inspect the API call that the web UI does, the trick seems to be setting an empty value for
encrypted_value, but I can't find this documented anywhere.Some related issues (I can file new issues if that's preferred):
gh secret setresetting visibility is a big footgun. We just had an outage because of this. The documentation saysSet a value for a secret on one of the following levels
That does not suggest to me "and wipe out the visibility settings already there". I think the documentation needs to make this much more clear. Perhaps if a secret already exists, require explicitly setting visibility until/unless this issue is resolved.
Minor, but the visibility flag documentation doesn't specify that you need to also list repos if you set visibility to "selected". Would be helpful to add that.
Not being able to modify only certain fields on a secret seems like a pretty big limitation in the API. I'm not sure the CLI should actually be hacking around that. Doing a
GETfollowed byPUTintroduces race conditions and such. Seems like the API should really have aPATCHmethod.Reacted by Shane McLaughlinI have a similar problem when I try to update secret selected repositories WITHOUT wanting the change the secret value:
I think it will be cumbersome to add extra
gh secretcommands for that. We can manage it either with tags or appropriate behavior
Describe the feature or problem you’d like to solve
Background: our organization secrets
-oare selectively shared w 1-20 repos, but not all. A sibling organization has the need to share some of the same secrets with a few of its repos.Currently, when you run
gh secret set MY_SECRET -o myOrgit'll reset the secret's visibility toprivateYou can add
--reposand then list them all...and there are a lot. And that list has to be maintained as repos come/go.Proposed solution
secret update: if a secret exists, update the value but change nothing else about its visibility or repo assignments.This is aimed at org-level secrets since repo-level secrets don't care about visibility/sharing, but I'd keep the same -o -a and -R flags from
secret setfor consistency.