Support setting user Codespaces secrets#4699
Conversation
mislav
left a comment
There was a problem hiding this comment.
Thanks! This feature looks great.
Left some comments, but the biggest blocker remains the uncertainty about the type of the selected_repository_ids parameter. Let us know what you learn!
|
Thanks for the review @mislav, I've filed issues with some internal teams to get the The Actions API is incorrectly documented and does expect those to be integers. |
| Secrets can be set at the repository, environment, or organization level for use in | ||
| GitHub Actions. Run "gh help secret set" to learn how to get started. | ||
| `), | ||
| Annotations: map[string]string{ |
There was a problem hiding this comment.
Resolved conflicts with #4675, with this change secrets would no longer just be an Actions command. Let me know if there's a better tag here.
Visibility is only meant for org secrets. User secrets do support scoping to specific repositories, but for that the `--repos` flag can be used without passing `--visibility`.
Let the platform perform validation. We gain nothing from client-side validation other than avoding an API request. By performing client-side validation, we open ourselves to the risk of falling out of sync with what the plaform considers valid secret names.
Do not use `Flags().Changed(...)` when testing for whether a flag has a non-empty value or not. The user might have intentionally sent an empty value.
Ensure the `--repos` list is parsed with the host of the repository as the default host in the case repositories are listed in the `repo` or `owner/repo` formats (which are also most likely).
mislav
left a comment
There was a problem hiding this comment.
This looks great!
I have pushed fixes:
gh secret set --useris now usable when not in a context of a local git repository--visiblityis now unsupported for--usersecrets- do not send the
visibilityJSON parameter when setting user secrets since that's ignored by the API endpoint - improve docs to clarify different secret levels (repo/environment/org/user)
- improve flag parsing and error formatting in
secret set - fix
secret set --reposfor GitHub Enterprise - remove client-side validation of secret names (just for good measure)
@joshmgross The remaining items are now that gh secret list and gh secret remove do not support --user. Do you have time to add those too? I suspect it will be simple. Should that be added in a separate PR? You can base it on this branch.
|
Thanks @mislav, your changes look good to me. I completely missed that user secrets didn't have visibility options like organization secrets. I can add support for |
|
@joshmgross Ah, right! The |
|
Adding |
Supports #4698
This PR adds support for setting a Codespaces user secret via the CLI.
Codespaces user secrets follow a similar pattern to Actions organization secrets in that they can be shared with all repositories or a specific set of repositories.
To support this, this PR uses the public key and set secret APIs for user Codespaces secrets.
https://docs.github.com/en/rest/reference/codespaces#get-public-key-for-the-authenticated-user
https://docs.github.com/en/rest/reference/codespaces#create-or-update-a-secret-for-the-authenticated-user
Repository selection
Unlike organization secrets, the repositories specified for a user secret do not have to belong to that owner of the secret.
When setting an organization secret via the CLI, the
--reposoption is used to specify a set of repository names.For user secrets, I've reused that same
--reposoption but with the assumption that all repositories specified are fully qualified names with owners (NWOs).If this is confusing, we could either:
--reposI did not use the second option as I'm unsure how to retrieve the current user's login.
Auth Issues
These APIs require the
userorread:userscope, which is not currently requested by default.Users will need to request the
userscope to set a user secretSince setting a secret first fetches the public key which requires
read:userscopes and the set secret API requiringuserscopes, users may hit auth issues twice before they are successful.Testing
Validated that a secret was able to be added:
Fixes #4038