label command

Describe the feature or problem you’d like to solve

I would love a way to manage my issue labels from the gh tool.

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 view`

Open the repository labels page.
(example: https://github.com/bradgarropy/bradgarropy.com/issues/labels)

gh label view

`gh label list`

List all labels in the repository.

gh label list

`gh label create`

Create a label.

name	example	description	required
`name`	`todo`	Issue name.	yes
`description`	`Need to accomplish this.`	Describe the label.	no
`color`	`#eeeeee`	Background color.	no

gh label create todo "Need to complete this." #eeeeee

`gh label clone`

Create a label.

name	example	description	required
`repo`	`bradgarropy/adobe-lunch`	Destination repository.	yes
`clobber`	`--clobber`	Clobber destination labels.	no

gh label clone bradgarropy/adobe-lunch --clobber

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 😢

Please also facilitate label assignment to issues/pull requests perhaps as:

gh label assign [id or url]

I've built a cli app named gh-label using Go. It helps you export and generate issue labels. It uses json files 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 😢

I do have a CLI lying around as well for labels. It actually offers a command to register gh aliases: https://github.com/SirWindfield/gh-labels-cli. You can simply run gh-labels integration install and 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 --purge

The 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 :)

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.

Definitely something that I'm looking forward to be implemented

We'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 clone for now
When running gh label create and no color is specified, gh should select a random color from the palette:
- #B60205
- #D93F0B
- #FBCA04
- #0E8A16
- #006B75
- #1D76DB
- #0052CC
- #5319E7
- #E99695
- #F9D0C4
- #FEF2C0
- #C2E0C6
- #BFDADC
- #C5DEF5
- #BFD4F2
- #D4C5F9

@vilmibm

Instead of cloning, perhaps consider an export and import command 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 test and got

HTTP 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 label command 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 the gh pr view 123 behaviour.

The 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 create command should do the same.

@mishabruml

@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 list command which shows the title, color, and description of every label in a repo.

@heaths The label import/export command ideas are a good one, it seems like they would function as a more generic form of a label clone command 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 the label clone command as I don't have a good sense of where someone might want to import/export repo labels to except to another repo.

@samcoe

@samcoe for my extension I decided on import/export mainly because of the issues - especially for extensions - off authenticating against repos. Apart from the -R command 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 a clone.

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 create and import subcommands try to do an upsert. While some may argue a single label create command doesn't need an upsert, a label clone or label import definitely 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

@heaths Thanks for the explanation. Seems like going with a single label clone command would be sufficient to start. I agree that it should support some sort of --overwrite flag 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 --force switch 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 like choco, scoop, winget, etc., that use either upgrade or update verbs 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 --force to force overwriting would be nice.

And is clone something someone is already working on, or are you looking for help?

@heaths

@heaths I don't have strong feelings about --overwrite and I think --force would also be suitable as long as the flag description appropriately describes the behavior.

I opened up #5441 for the label clone work and marked it as "help wanted" if you would like to pick it up.

+1 for gh label view

I 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 listed

So 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 listed

Now 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.

feat: redact content from a message in a session (cli#446)

auto compare and clone labels

Navigation Menu

Repository navigation

label command #446

Describe the feature or problem you’d like to solve

Proposed solution

`gh label view`

`gh label list`

`gh label create`

`gh label clone`

Additional context

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

label command #446

Description

Describe the feature or problem you’d like to solve

Proposed solution

gh label view

gh label list

gh label create

gh label clone

Additional context

Activity

EmilyGraceSeville7cf commented on Apr 14, 2020

erdaltsksn commented on Jul 21, 2020

Additional context

mainrs commented on Mar 17, 2021

BenjamenMeyer commented on Apr 21, 2021

BenjamenMeyer commented on Apr 21, 2021

Corfucinas commented on Feb 1, 2022

vilmibm commented on Feb 14, 2022

heaths commented on Mar 30, 2022

mishabruml commented on Apr 5, 2022

heaths commented on Apr 5, 2022

samcoe commented on Apr 7, 2022

heaths commented on Apr 7, 2022

samcoe commented on Apr 11, 2022

heaths commented on Apr 11, 2022

samcoe commented on Apr 11, 2022

bitdivine commented on Mar 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`gh label view`

`gh label list`

`gh label create`

`gh label clone`