https://docs.travis-ci.com/user/encryption-keys/

See https://www.reddit.com/r/golang/comments/515t2z/adding_a_version_number_to_go_packages_with_go/

Prefer this over ldflags so go get works perfectly. Will run on CI master only.

mislav/hub#1225

Internal gh wrapper library is hacky with errors.

Labels with spaces in them, such as status = needs review won't be deleted, and ghlabels won't report an error because of it's idempotent nature.

Workaround:

set REPO "go/wapi"; ghlabels pull $REPO | jq ".[].name" | xargs -I "%" sh -c "ghlabels delete $REPO \"%\"; echo deleted $REPO:%"        

my body

Makes more sense and --defaults is misleading, it deletes any label with the same name as a default label, even if the color is changed.

my body
dsamldasdas

Only useful tests would be integration tests against the github API.

meow meow

my body

I'm thinking a command like ghrepos will write to stdout all the repos in the org and then that makes it very easy to chain with ghlabels.

Main command

ghlabels sync <org>/<repo> <org>[/<repo>]

Copy labels from one repo to another org or repo. Will never delete labels except for the default labels, unless they too are in the from repo. For labels that already exist, it will just update them.

Why not have a workflow where one pulls into config and then pushes out somewhere?

Just seems like worse UX. Having a config file doesn't really help much in this case because you still want an initial repository from which to pull labels (unless you're a masochist and want to build the json config yourself) and then you also want to make it easy to edit the labels as well which is super easy to do with a repo on github. Using a config file just adds an extra step to the whole process to sync it. I could go an alternate route with the workflow and let you specify exactly what labels to pull and push (then you could pull from the repository you just made your changes on) but that seems more complicated a workflow than this.

Backups with the config file is a moot point because your github repos should be backed up regularly anyway.

Others

These two are needed because the sync command doesn't let you delete or rename labels. This should rarely happen anyway.

Rename command

ghlabels rename lablelBefore labelTo <org>[/<repo>]

Delete command

ghlabels delete label <org>[/<repo>]

Implementation

Will finish the implementation in #5

With solid support for versioning and help.