You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, ci-reporter will not work for private repositories because the CI providers that private repos use require an API key for private builds. Here are the things that need to happen for private repo support to be possible:
A UI (or some other method) to encrypt API keys
Store encrypted API keys in the .github/ci-reporter.yml file
Use those keys in API calls to CI providers
To be clear, I do not want to resort to using a database for these keys. There is too much overhead involved, and I'd like to nail down a good pattern for encrypting/storing keys in repositories since it'll have implications for many more apps.
The text was updated successfully, but these errors were encountered:
What would be an appropriate key to use to encrypt these secrets - the private key that the GitHub app has?
I investigated if Circle has a tidy way to generate an API key with a limited set of permissions but it does not so that would need to be communicated to the user, likely during the install & redirect phase of application install.
I think short of GitHub providing a store for secret material the best we can do is your prescribed approach.
What's the consensus between:
A) showing the user the encrypted key and asking them to commit it to config.yml
B) granting the application repository write permissions to abstract away the additional install step outlined in A?
Currently, ci-reporter will not work for private repositories because the CI providers that private repos use require an API key for private builds. Here are the things that need to happen for private repo support to be possible:
.github/ci-reporter.yml
fileTo be clear, I do not want to resort to using a database for these keys. There is too much overhead involved, and I'd like to nail down a good pattern for encrypting/storing keys in repositories since it'll have implications for many more apps.
The text was updated successfully, but these errors were encountered: