Repository navigation
secret update #6327
Description
Describe the feature or problem you’d like to solve
Background: our organization secrets -o are 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 myOrg it'll reset the secret's visibility to private
You can add --repos and 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 set for consistency.
Activity
vilmibm commentedon Sep 29, 2022
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).
nsmag commentedon Oct 6, 2022
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 secretvisibility = privatevisibilityvisibility = selected, maintainreposPUTthe secret withvisibilityandreposThere's no changes if
--visibilityor--reposare not empty.A few things I'm not sure about this solution:
reposif the selected repos count is big.What do you think?
danielfn commentedon Apr 7, 2023
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.GMNGeoffrey commentedon May 24, 2023
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 saysThat 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.yvele commentedon Jul 29, 2024
I have a similar problem when I try to update secret selected repositories WITHOUT wanting the change the secret value:
gh secretset selected repositories without re-defining the value #9383I think it will be cumbersome to add extra
gh secretcommands for that. We can manage it either with tags or appropriate behavior