Code Monkey home page Code Monkey logo

labels's Introduction

labels

CLI app for managing GitHub labels for Python 3.6 and newer. ๐Ÿ“

Installation

labels is available for download from PyPI via pip:

pip install labels

Versions follow Calendar Versioning using a YY.MINOR.MICRO scheme. ๐Ÿ—“

Authentication

The labels CLI connects to the GitHub API to modify labels for a GitHub repository. Please create your own personal API token and choose the correct token scope based on whether you want to manage issue labels for a public or a private repository. Then set up two environment variables in your terminal:

export LABELS_USERNAME="<GITHUB_USERNAME>"
export LABELS_TOKEN="<GITHUB_TOKEN>"

Usage

Once you've installed labels and set up the environment variables, you're ready to use the labels CLI to manage labels for a GitHub repository. The CLI comes with two commands: fetch and sync. Both commands require the name of the owner and the name of the GitHub repository to fetch from or sync to. By default, labels tries to load this information from your local Git repository based on the URL for the origin remote repository.

For example, if you run labels from your local clone of the earth repository with origin set to [email protected]:hackebrot/earth.git owner will be hackebrot and repo will be earth. ๐ŸŒ

You can override one or both of these values manually using the following CLI options:

-o, --owner TEXT     GitHub owner name
-r, --repo TEXT      GitHub repository name

Fetch

When you use labels for the first time, you will start by fetching information about the existing labels for your GitHub project. The CLI will then write a TOML file to your computer with the retrieved information. The default name for this file is labels.toml in your current working directory and can be changed by passing the -f, --filename PATH option followed by the path to where you want to write to.

labels fetch -o hackebrot -r pytest-emoji
[bug]
color = "ea707a"
description = "Bugs and problems with pytest-emoji"
name = "bug"

["code quality"]
color = "fcc4db"
description = "Tasks related to linting, coding style, type checks"
name = "code quality"

[dependencies]
color = "43a2b7"
description = "Tasks related to managing dependencies"
name = "dependencies"

[docs]
color = "2abf88"
description = "Tasks to write and update documentation"
name = "docs"

["good first issue"]
color = "bfdadc"
description = "Tasks to pick up by newcomers to the project"
name = "good first issue"

Sync

Now that you have a file on your computer that represents your GitHub labels, you can edit this file and then run labels sync to update the remote repository. But first let's look into how that works... ๐Ÿ”

Representation of a GitHub label in the written TOML file:

[docs]
color = "2abf88"
description = "Tasks to write and update documentation"
name = "docs"

The section name ([docs] in the example above) represents the name of the label for that repository and is identical to the name field when running labels fetch. Do not edit the section name of existing labels yourself!

The fields color, description and name are parameters that you can edit with the labels CLI.

  • name - The name of the label
  • description - A short description of the label
  • color - The hexadecimal color code for the label without the leading #

You can make the following changes to labels for your repo:

  • You can delete a label by removing the corresponding section from the labels file ๐Ÿ—‘
  • You can edit a label by changing the value for one or more parameters for that label ๐ŸŽจ
  • You can create a new label by adding a new section with your desired parameters ๐Ÿ“

When creating labels choose a section name identical to the name parameter.

Check your label changes before syncing by using the dryrun CLI option:

-n, --dryrun         Do not modify remote labels

Example usage:

labels sync -n -o hackebrot -r pytest-emoji
This would delete the following labels:
  - dependencies
This would update the following labels:
  - bug
  - good first issue
This would create the following labels:
  - duplicate
This would NOT modify the following labels:
  - code quality
  - docs

Running labels sync without the dryrun option also updates the labels file, so that section names match the name parameter.

If labels encounters any errors while sending requests to the GitHub API, it will print information about the failure and continue with the next label until it has processed all of the labels.

Community

Please check out the good first issue label for tasks, that are good candidates for your first contribution to labels. Your contributions are greatly appreciated! Every little bit helps, and credit will always be given! ๐Ÿ‘

Please note that labels is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

License

Distributed under the terms of the MIT license, labels is free and open source software.

labels's People

Contributors

hackebrot avatar jean avatar mfonism avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

labels's Issues

Handle differences in capitalisation

If labels.toml has blocked, and Blocked already exists:

DEBUG labels sync: Creating label 'blocked' for owner/repo
Error creating label blocked: 422 - Unprocessable Entity

One approach: compare lowercased labels, and silently update to whatever is in labels.toml. E.g. in this case Blocked->blocked.

Another approach: fail, saying that there is a case mismatch.

Add Python 3.7 to package, docs, and tests

We currently don't officially support Python 3.7. It's time we add Python 3.7 to the package information in setup.py, the README file and to the test environments. ๐Ÿš€

Feature Request: label issues

๐Ÿ‘‹ To enable issue triage, I'd like to be able to:

  • list issues that are (un)labelled
  • label issues

Do you think these are a good fit / in scope for this project?

Add -f, --file FILENAME option

First off, thanks for making this tool! I have been looking all day for what I assumed would be a common/straightforward task of exporting and importing GitHub Labels between repositories. Most of the older tools have not been updated since the February 2018 Label improvements and do not transfer Label Descriptions. And the use of TOML is a huge improvement over XML, JSON, and YAML implementations, in my opinion.

I wonder if the project could benefit from allowing the labels.toml default filename to be overridden using a -f FILENAME or --file FILENAME flag syntax. This would allow a user to have a repository that would sync the GitHub labels from many projects, e.g. repo1.toml, repo2.toml, ....

Other ideas that came across my mind are:

  • Update README.md to describe the -u and -t flags
  • Add write command that would not delete target repository labels as sync might do, but adds/replaces conflicts with only the contents of labels.toml. Would not change/update contents of labels.toml (assuming section names match their names parameters).

I see your CONTRIBUTING.md is under construction, but I would be happy to submit a PR for some/all of these feature requests.

[Feature proposal]: Reuse same color for multiple labels

Consider the following labels.toml file:

[linux]
color = "25d4dd"  # platform label
name = "linux"
description = "The issue relates Linux support."

[macOS]
color = "25d4dd"  # platform label
name = "macOS"
description = "The issue relates to Apple macOS support."

[windows]
color = "25d4dd"  # platform label
name = "windows"
description = "The issue relates to Microsoft Windows support."

As you can see, some of the platforms have the same color intentionally. This is due to the reason that they represent the same type of label. It would be nice if one could do the following:

[colors]
platform = "25d4dd"

[linux]
color = "platform"
name = "linux"
description = "The issue relates Linux support."

[macOS]
color = "platform"
name = "macOS"
description = "The issue relates to Apple macOS support."

[windows]
color = "platform"
name = "windows"
description = "The issue relates to Microsoft Windows support."

What do you think? Once you approve, I will implement it.

Infer labels owner and repo from git in working directory

Currently fetching and syncing labels with a GitHub repository requires the --repo and --owner CLI options. I think it would be awesome if we could infer this information from the current working directory and the corresponding Git repository ๐Ÿ˜ƒ

labels fetch
labels sync

Feature request: merge labels

Given input like the following, I'd like all issues with the mergeme label to get the bug label, and for the mergeme label to be deleted.

[bug]
color = "d73a4a"
name = "bug"
description = "Something isn't working"

[mergeme]
color = "f9d0c4"
name = "bug"
description = "To be merged with 'bug' label"

This requires the issue labelling functionality requested in #6

Feature Request: Can this be turned into a GitHub App?

Thanks for this project, I found it really useful, but I'm uh... lazy.. when it comes to command line ๐Ÿ˜ฅ ๐Ÿ™‡โ€โ™€๏ธ

I think it would be great for this to exists as a GitHub App, and easily installed to any repo we like.
I'll be interested to help build such app :)

A few Proposal(s) : CLI args improvement, GitHub Enterprise support

Hey @hackebrot
I would like to propose the following changes

  1. Remove -u | --username option and use token via HTTP headers.
    It is not necessary and github will soon stop supporting password based authentication to its APIs. username is not necessary if HTTP headers are used, see this.

  2. This might be better suited under bugs. Because how click args are defined, --help is useless
    for fetch and sync without specifying -t | --token as it gives an error.

      Usage: labels [OPTIONS] COMMAND [ARGS]...
      Try "labels --help" for help.
    
      Error: Missing option "-t" / "--token".
    
  3. Support GitHub enterprise
    I think adding an optional argument which defaults to api.github.com should be sufficient. (for SSL system certs should be used, as its the most sane option)

  4. for option above, and for the token I would like to propose that we use GITHUB_URL and GITHUB_TOKEN as env variables as they are better in my opinion than LABELS_TOKEN

  5. Because above changes are breaking changes we need to bump minor version

  6. Docker
    docker
    I am not proposing that you provide docker images. because I already do it anyway and will be happy to maintain the images on GitHub and DockerHub.

  7. May be I am spoiled by Go. Use Pyinstaller for packaging it into a binary? its always nice to have a self contained static binary.(I know about libc requirements) Though, I am not too keen on this one.

  8. This one may be my peeve, isort and black for formatting?

I have already completed work on most of them, (needs a bit more testing for GitHub Enterprise) and will be happy to submit PR(s) if you are willing to accept any of these.

Don't `exit` during a dry run?

I'm using labels in an unorthodox way: I'm driving it from another package.
Specifically, I'm spreading out updates over groups of repositories:

    for repo in open(Path(group) / 'repos.txt').readlines():
        repo = repo.strip()
        workfile = Path(group) / 'workdir' / f'{repo}.toml'
        context.invoke(labels_cli.fetch_cmd, owner='...', repo=repo, filename=workfile)
        merge_labels(Path(group) / 'labels_to_update.toml', workfile)
        delete_labels(Path(group) / 'labels_to_delete.txt', workfile)
        # This may fail with labels that really require merging:
        context.invoke(labels_cli.sync_cmd, owner='...', repo=repo, filename=workfile, dryrun=dryrun)
    if not dryrun:
        rename_standard_labels(Path(group) / 'labels_to_update.toml')

This stops after the first iteration due to this line.

  • Would it be OK to just turn that into a return?
  • The reason why I'm invoking commands is that a lot of work is done in the *_cmd implementations, specifically sync_cmd. Maybe it's worthwhile moving this out to labels/commands.py or someplace, to make labels more amenable to use as library. Does this make sense?

Don't `exit` if a renamed label wasn't found

If we see a request to rename a non-existent label, just complain and continue with the rest of the work.

iff --git a/src/labels/cli.py b/src/labels/cli.py
index 6cb7723..55e516d 100644
--- a/src/labels/cli.py
+++ b/src/labels/cli.py
@@ -204,7 +204,7 @@ def sync_cmd(
                     f'parameter: "{local_label.name}"',
                     err=True,
                 )
-                sys.exit(1)
+                labels_to_ignore[remote_name] = local_label

I'm driving labels from another package, running it across many repos.
Some repos may not have the label that I'm renaming.
I'd like it to skip the missing label and continue.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.