joffrey-bion/bob

A CLI wizard to setup secrets for a Github repository by fetching API keys from well known websites

bob's Issues

Rework providers with a more generic approach

We should be able to define providers as an independent module with the following:

• name (used to enable the provider (e.g. bintray, enabled by --bintray flag)
• an OptionGroup of command line options to add when the provider is enabled
• an implementation to fetch secrets, returning a common Secret type (with name and value)

From this, the list of providers should be used to configure the main set-github-secrets command.

Rework username / repo name approach

• The login just requires the token
• The repository could be provided in the form user/repo.
• Multiple repositories could be provided with different orgs or users.

Maybe the username could be optional, then?

Command to check git project statuses

This is useful when changing laptops to verify that all local git projects are clean and no local changes will be lost in the process.

The command could work in a way similar to https://github.com/fboender/multi-git-status

At least it could do this kind of things:

• Browse a folder hierarchy for git projects
• Show dirty workspaces
• Show unpushed commits
• Fetch and detect unfetched commits? This could make it harder to see whether something was force pushed to origin and we should discard local commits, or if the local commits should be consider

Split fetch-keys and set-github-secrets commands

Fetching keys can take some time and it could be useful to do it only when we want to update keys, or fetch them the first time.

Setting secrets can be done on multiple repositories in multiple commands, and it would be useful to have it as a separate command.

Doing this requires deciding on a way to store the data, which may not be obvious given the sensitivity.
We could provide several options:

• [windows-only] set secrets as environment variables in the local system
• set secrets in a plain text file (at a given path), maybe by default under ~/.ghsecrets
• if possible, store it in the system-dependent credential manager / key ring (is there a java API for this?)