Skip to content

Support setting user Codespaces secrets#4699

Merged
mislav merged 11 commits intocli:trunkfrom
joshmgross:joshmgross/codespaces-set-secret
Nov 18, 2021
Merged

Support setting user Codespaces secrets#4699
mislav merged 11 commits intocli:trunkfrom
joshmgross:joshmgross/codespaces-set-secret

Conversation

@joshmgross
Copy link
Contributor

@joshmgross joshmgross commented Nov 7, 2021

Supports #4698

This PR adds support for setting a Codespaces user secret via the CLI.

gh secret set -u -bs -vselected -r"cli/cli,github/hub" cool_secret

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 --repos option is used to specify a set of repository names.

For user secrets, I've reused that same --repos option but with the assumption that all repositories specified are fully qualified names with owners (NWOs).

If this is confusing, we could either:

  1. Use a different option for fully qualified repos rather than reusing --repos
  2. Support both repository names and full NWOs. If an owner isn't specified, assume the owner is the current user.

I did not use the second option as I'm unsure how to retrieve the current user's login.

Auth Issues

These APIs require the user or read:user scope, which is not currently requested by default.

Users will need to request the user scope to set a user secret

gh auth refresh -h github.com -s user

Since setting a secret first fetches the public key which requires read:user scopes and the set secret API requiring user scopes, users may hit auth issues twice before they are successful.

>gh secret set -u -bs -vselected -r"cli/cli,github/hub" cool_secret
failed to fetch public key: HTTP 403: This API requires the `read:user` scope. (https://api.github.com/user/codespaces/secrets/public-key)
This API operation needs the "read:user" scope. To request it, run:  gh auth refresh -h github.com -s read:user

>gh auth refresh -h github.com -s read:user 
...

>gh secret set -u -bs -vselected -r"cli/cli,github/hub" cool_secret
failed to set secret: HTTP 403: This API requires the `user` scope. (https://api.github.com/user/codespaces/secrets/cool_secret)
This API operation needs the "user" scope. To request it, run:  gh auth refresh -h github.com -s user

>gh auth refresh -h github.com -s user
...

Testing

Validated that a secret was able to be added:

❯ bin/gh secret set -u -bs -vselected -r"joshmgross/clock,joshmgross/actions-testing" coolSecret
✓ Set secret coolSecret for cli/cli

image

Fixes #4038

@joshmgross joshmgross requested a review from a team as a code owner November 7, 2021 20:58
@joshmgross joshmgross requested review from vilmibm and removed request for a team November 7, 2021 20:58
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

@joshmgross joshmgross marked this pull request as draft November 8, 2021 22:27
@joshmgross
Copy link
Contributor Author

Thanks for the review @mislav, I've filed issues with some internal teams to get the selected_repository_ids type issues fixed.

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{
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@joshmgross joshmgross marked this pull request as ready for review November 11, 2021 04:08
@joshmgross joshmgross requested a review from mislav November 11, 2021 04:08
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).
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great!

I have pushed fixes:

  • gh secret set --user is now usable when not in a context of a local git repository
  • --visiblity is now unsupported for --user secrets
  • do not send the visibility JSON 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 --repos for 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.

@joshmgross
Copy link
Contributor Author

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 gh secret list and gh secret remove in a separate PR, but I don't think I'll be able to use this PR as a base branch since this is a fork pull request.

@mislav
Copy link
Contributor

mislav commented Nov 11, 2021

@joshmgross Ah, right! The list and remove commands are completely separate Go packages, so you might be able to base your changes on trunk just as well, even before this PR gets merged.

@joshmgross
Copy link
Contributor Author

Adding list and remove in #4714

@mislav mislav merged commit e82958b into cli:trunk Nov 18, 2021
@joshmgross joshmgross deleted the joshmgross/codespaces-set-secret branch November 18, 2021 15:57
@VictorBatta VictorBatta mentioned this pull request Dec 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clarify documentation for setting secret value from a file

2 participants