cc@HowardWolosky

I considered adding support for the Org-level secrets but put that on hold for now:
https://developer.github.com/v3/actions/secrets/#list-organization-secrets

So, something I was thinking about... since PowerShellForGitHub exposesInvoke-GHRestMethod andInvoke-GHRestMethodMultipleResult I was thinking about refactoring this PR to only include:

• Get-GitHubRepositoryPublicKey -https://developer.github.com/v3/actions/secrets/#get-a-repository-public-key
• Get-GitHubSecretInfo -https://developer.github.com/v3/actions/secrets/#list-repository-secrets andhttps://developer.github.com/v3/actions/secrets/#get-a-repository-secret
• Remove-GitHubSecret -https://developer.github.com/v3/actions/secrets/#delete-a-repository-secret

Then I'll make my own module calledCreateGitHubSecrets or something that depends onPSSodium andPowerShellForGitHub that will implement:

• Set-GitHubSecret -https://developer.github.com/v3/actions/secrets/#create-or-update-a-repository-secret
• New-GitHubSecret -https://developer.github.com/v3/actions/secrets/#create-or-update-a-repository-secret but with an "exists" check

I think that would totally unblock this in the short term, and provides an easy path towards movingNew/Set back into here at some point in the future (since they would have already been built on-top ofInvoke-GHRestMethod) should it become more clear that taking on external dependencies makes sense.

Alright I removed those but to write tests I need you to add a couple test secrets to either one of the test repos or to this repo. Let me know when you do that - I can't get the value so set that to whatever. The name can be whatever you want but share those here for me.

Would an organization secret work? A secret stored in this repository won't help, because the accounts that are used while running CI don't have access to this repo. And there currently is no repo that is guaranteed to exist in any of the test accounts...but theorganization is guaranteed to be available, so I could add a secret to the test organizations.

If you do this though, you should add a comment to the tests (and to the CONTRIBUTING.md documentation in the tests section) to indicate that there is the expectation for those secrets to exist in the test organization in order for those tests to succeed...

No I don't think org secrets will work. That's a separate API and should be tested in and of itself.

@HowardWolosky if this gets completed and merged I would happily contribute a Powershell SecretManagement Provider that would leverage this API to easily fetch repository secrets.
https://github.com/powershell/secretmanagement

@JustinGrote the problem is that there's no way to retrieve the value of secrets. You can set them and list meta data about them, but you can't get them.

FWIW, my org just ran into this this week. We have a use case where we may be provisioning repo-level secrets in bulk from an external source - being able to callNew-GitHubSecret or similar across multiple repos would be a huge help.

(Org level secrets aren't applicable, since we have different secrets per team - the current PoR involves replicating the same team-scoped secret across many repos, which doesn't feel great.)

Not sure if this is still on the roadmap for the module (seems like there hasn't been commits in a couple of years), but it'd be great to get a temperature-check on iteration in this area.