Repository navigation
label command #446
Description
Activity
Please also facilitate label assignment to issues/pull requests perhaps as:
gh label assign [id or url]Reacted by Junyeong Jeong, Geoffrey Martin-Noble, Ajay Mehta, mira01, Jesse Adelman, Rob Cowsill, Karsten Siemer and Daniel FarrellI've built a cli app named gh-label using Go. It helps you export and generate issue labels. It uses
jsonfiles to hold label list. I also add a few starter label list to use.If the maintainers are okay with this feature, I'm willing to implement this feature.
NOTE: I hope I can implement it.
Additional context
I made a tool called labman which handles cloning labels between repos. Should be a great reference!
I'd make some PRs myself, but I don't know Go 😢
Reacted by Brad GarropyI do have a CLI lying around as well for labels. It actually offers a command to register
ghaliases: https://github.com/SirWindfield/gh-labels-cli. You can simply rungh-labels integration installand the alias gets registered.I mostly use it in two scenarios:
- Create repo-specific labels. You can define template colors inside the label definition file (LDF) and create labels based on those. I linked my LDF inside the repo's readme. If I want to create a new label (for example for a new package insdie a monorepo), I usually run
gh labels create --template component --name .... - To bulk-create a standard set of labels during repo creation. I created a custom alias that invokes the CLI after initializing a new repository using
gh:
$ gh alias set -s new 'gh repo create $1; cd $1; gh labels update --purge' - Adding alias for new: gh repo create $1; cd $1; gh labels update --purgeThe command deletes all labels inside a repository (
--purge) and creates all labels defined inside your LDF.Take a look at the README file for more about the LDF and where to place it :) Hopefully this is as useful for others as it is to me :)
- Create repo-specific labels. You can define template colors inside the label definition file (LDF) and create labels based on those. I linked my LDF inside the repo's readme. If I want to create a new label (for example for a new package insdie a monorepo), I usually run
As an organization owner (of several actually) I'd like to be able to standardize labels across the repositories in my organizations.
To facilitate that, it'd be nice if there was a way to apply the actions against all repositories in an organization; by default though it should work on a specified repository since GitHub doesn't have organization level labels.There should also be a separate command to delete a specified label.
Reacted by Rob Cowsill and Daniel FarrellDefinitely something that I'm looking forward to be implemented
Reacted by Emily Grace SevilleWe're opening this up for help wanted as we'd be happy to merge it into core (or check out an extension that could be merged).
The UX outlined above is a good start with the following amendments/clarifications:
- Hold off on
gh label clonefor now - When running
gh label createand no color is specified,ghshould select a random color from the palette:- #B60205
- #D93F0B
- #FBCA04
- #0E8A16
- #006B75
- #1D76DB
- #0052CC
- #5319E7
- #E99695
- #F9D0C4
- #FEF2C0
- #C2E0C6
- #BFDADC
- #C5DEF5
- #BFD4F2
- #D4C5F9
Reacted by Emily Grace Seville, Benjamen Meyer, Eduardo Robles and Pedro Torres- Hold off on
Instead of cloning, perhaps consider an
exportandimportcommand which, on their own, could also be useful. Perhaps someone wants to import a bunch of labels via CSV or TSV, like managed in Excel.For that currently, I have the heaths/gh-label extension and, @vilmibm, if interested could add those in a separate PR.
Hey, would love if the feature here #2196 was addressed. I just tried out creating a label that already exists i.e.
gh label create testand gotHTTP 422: Validation Failed (https://api.github.com/repos/****/****/labels) Label.name already exists
IMO gh cli should create if not exist already, or exit gracefully if already exist
Should I use this issue to track feature requests against the
gh labelcommand or open a new one?Another feature I think would be useful is listing/viewing specific labels e.g.
gh label view test, similar to thegh pr view 123behaviour.Reacted by Emily Grace SevilleThe REST and GraphQL APIs do not support an upsert, which is why in https://github.com/heaths/gh-label I first try a create and, if that fails, update. IMO, the
gh label createcommand should do the same.Reacted by Misha Bruml@mishabruml I think it would be best to open up new issues for continued label work.
I agree that the error message could be better for when a label already exists, that should be a fairly easy fix.
I am not sure I understand the use case for viewing a label when we already have the
label listcommand which shows the title, color, and description of every label in a repo.@heaths The
label import/exportcommand ideas are a good one, it seems like they would function as a more generic form of alabel clonecommand that works between two repos. My question would be do we actually need a more generic form? Or is one simplified command,label clone, a more streamlined approach that covers the majority of cases that users will want? Personally, I feel more value would be created with thelabel clonecommand as I don't have a good sense of where someone might want to import/export repo labels to except to another repo.Reacted by Shinigami and Emily Grace Seville@samcoe for my extension I decided on import/export mainly because of the issues - especially for extensions - off authenticating against repos. Apart from the
-Rcommand line switch, which supports optional enterprises, optional orgs (assumes your username otherwise), and repo name, there are environment variables which can be used for the source repo. All of that - and not sure how that would work for env vars - would probably have to be replicated for the target repo for aclone.Export on its own could also be useful, as you could dump to a csv/tsv, open it in Excel or similar, and make modifications, then re-import into the same repo in bulk.
Speaking of which, because there are no bulk or bulk-friendly operations for labels in the GitHub REST or GraphQL APIs, is why both my
createandimportsubcommands try to do an upsert. While some may argue a singlelabel createcommand doesn't need an upsert, alabel cloneorlabel importdefinitely should because the target repo may have some, but not all, labels you want to clone/import.I created my extension, for example, to help unify the Azure SDK repos that we use the same labels across all them. The colors themselves are also import to match exactly, since we have bots that may do different actions based on the colors e.g., we have a single color we use to represent all the different services we currently support. But it's not uncommon that those repos will have some labels and not all, and even if they do have the same label name we also want to make sure it's been updated (e.g., same color) from the source repo.
Ideally, the service supports an upsert for labels since it'd be faster and easier than two network calls, but it's still achievable by a create + update, if necessary.
@heaths Thanks for the explanation. Seems like going with a single
label clonecommand would be sufficient to start. I agree that it should support some sort of--overwriteflag that will do the upsert operation, but I would be hesitant to have that be the default behavior and would rather see the user have to opt in to a potentially destructive operation.How would you feel about a
--forceswitch intead? More common, or do you feel it's too vague in this case? Personally - though I've seen the same gripe from others, though anecdotal at best - I get a little annoyed when CLIs have similar commands with different names. For example, on Windows we have deployment managers likechoco,scoop,winget, etc., that use eitherupgradeorupdateverbs for upgrades. There's also switches that are similar but different. It's always a guessing game to remember which verb/param I use in which context. Ergo, using--forceto force overwriting would be nice.And is
clonesomething someone is already working on, or are you looking for help?+1 for
gh label viewI see the comment about "why not just use list". List with search can be used, but use it and it quickly becomes clear why this is not very ergonomic:
gh label list --search REDACTED Showing 30 of 174 labels in redacted NAME DESCRIPTION COLOR ... 30 labels are listedSo it spams the screen. Try to fix with
--limit 1:gh label list --search REDACTED --limit 1 Showing 30 of 174 labels in redacted NAME DESCRIPTION COLOR ... 1 label is listedNow it provides just one label BUT one needs to look carefully, because if the requested label doesn't exist, the closest entry will be listed. This invites errors.
- added a commit that references this issue
on Jul 21, 2025 - added a commit that references this issue
on Aug 13, 2025
Describe the feature or problem you’d like to solve
I would love a way to manage my issue labels from the
ghtool.For example, clone labels from repo to repo, list labels, create a label, update a label, etc.
Proposed solution
Here are the commands that I'm proposing
gh label viewOpen the repository labels page.
(example: https://github.com/bradgarropy/bradgarropy.com/issues/labels)
gh label listList all labels in the repository.
gh label createCreate a label.
nametododescriptionNeed to accomplish this.color#eeeeeegh label cloneCreate a label.
repobradgarropy/adobe-lunchclobber--clobberAdditional context
I made a tool called labman which handles cloning labels between repos. Should be a great reference!
I'd make some PRs myself, but I don't know Go 😢