Code Monkey home page Code Monkey logo

labelmaker's Introduction

Project Status: Active – The project has reached a stable, usable state and is being actively developed. CI Status codecov.io Minimum Supported Rust Version MIT License

GitHub | crates.io | Issues | Changelog

labelmaker is a Rust program for batch creation of labels in GitHub repositories, including updating and/or renaming existing labels to meet your specifications. Simply describe your desired labels in a configuration file and point labelmaker in the direction of your repositories.

Installation

In order to install labelmaker, you first need to have Rust and Cargo installed. You can then build the latest release of labelmaker and install it in ~/.cargo/bin by running:

cargo install labelmaker

Usage

labelmaker [<global options>] <subcommand> ...

The labelmaker command has the following subcommands, each detailed below:

  • apply — Apply a set of label specifications to one or more GitHub repositories

  • fetch — Dump a repository's labels as a configuration file

  • make — Create or update a single label

Each subcommand takes an argument or option for indicating what GitHub repositories to operate on. A repository can be specified in the form OWNER/NAME (or, when OWNER is the authenticated user, just NAME) or as a GitHub repository URL. If no repository is supplied, then the current directory must belong to a Git repository whose origin remote points to a GitHub repository; labelmaker will operate on this remote repository.

Global Options

  • -l <level>, --log-level <level> — Set the log level to the given value. Possible values are "OFF", "ERROR", "WARN", "INFO", "DEBUG", and "TRACE" (all case-insensitive). [default value: INFO]

Authentication

labelmaker requires a GitHub access token with appropriate permissions in order to run. Specify the token via the GH_TOKEN or GITHUB_TOKEN environment variable or store it with the gh command.

Note that, if gh has stored the token in a system keyring, you may be prompted to unlock the keyring.

labelmaker apply

labelmaker [<global options>] apply [<options>] <config-file> [<repository> ...]

labelmaker apply takes a path to a configuration file (See "Configuration File" below) and a list of GitHub repositories as arguments. It then creates and/or updates the labels of each repository based on the specification in the configuration file.

For each repository, all changes are calculated before modifying anything, so if an error occurs based on the state of the configuration file and/or current repository labels, it will be caught before any changes to the repository are made.

Options

  • --dry-run — Do not change anything in GitHub, but do emit log messages showing what would be changed.

  • -F FILE/--repo-file FILE — Also operate on all repositories listed in the given file (or listed on standard input if FILE is -). Repositories must be listed one per line. Leading & trailing whitespace is ignored. Blank lines and lines starting with # are skipped.

  • -P NAME/--profile NAME — Specify which profile in the configuration file to use. Defaults to the value of defaults.profile in the configuration file, or to default.

labelmaker fetch

labelmaker [<global options>] fetch [<options>] [<repository>]

labelmaker fetch fetches the labels currently defined for the given GitHub repository and dumps them as a labelmaker configuration file, ready for input into labelmaker apply.

The generated configuration file lists only label names, colors, and descriptions, no defaults, aside from the file-wide color setting having its default value included for use as a reference.

Options

  • -o FILE/--outfile FILE — Output the configuration to the given file. By default, output is written to standard output, which can also be selected by supplying - as the outfile name.

    The format (JSON, JSON5, TOML, or YAML) of the output is determined based on the file's extension. When outputting to standard output, JSON is produced.

  • -P NAME/--profile NAME — Set the name of the profile to place the labels under in the generated configuration file. The configuration file's default profile will also be set to this value. [default: default]

labelmaker make

labelmaker [<global options>] make [<options>] <label-name>

labelmaker make creates or updates the label with the given name in a GitHub repository, the same as if labelmaker apply had been run on that repository with a configuration profile containing a single label entry.

Options

  • -c COLOR/--color COLOR — Specify the label's color. Colors are specified using the same formats as in the configuration file.

    This option can be specified multiple times, in which case one of the given colors will be picked at random when creating the label, and no change will be made to the label color when updating the label.

    The color defaults to a random selection from the same built-in list as used by the configuration file and apply.

  • --create/--no-create — Whether to create the label if it doesn't already exist [default: --create]

  • -d TEXT, --description TEXT — Specify the label's description.

  • --dry-run — Do not change anything in GitHub, but do emit log messages showing what would be changed.

  • --enforce-case/--no-enforce-case — Whether to rename an extant label if its name differs in case from the name given on the command line [default: --enforce-case]

  • --on-rename-clash <ignore|warn|error> — Specify what to do if the label exists and one or more --rename-from labels also exist:

    • ignore: Do nothing
    • warn (default): Emit a warning
    • error: Fail with an error
  • --rename-from LABEL — If LABEL exists, rename it to the label name provided as the argument to make.

    This option can be specified multiple times. If multiple --rename-from labels exist, an error will occur.

  • -R REPO/--repository REPO — Specify the GitHub repository to operate on.

  • --update/--no-update — Whether to update the label if its color and/or description do not match the values given on the command line [default: --update]

Configuration File

labelmaker's configuration file may be written in JSON, JSON5, TOML, or YAML; the file type is determined automatically based on the file extension. The file contains a top-level mapping with the following fields:

  • defaults — A mapping of default label settings to apply to all labels in this configuration file. Any field that can be set on a label can be set here, other than name and rename-from. File-wide defaults can be overridden for specific profiles via the profiles.*.defaults mappings.

    • The defaults mapping may also contain a profile string field specifying the default profile for apply to use when no --profile option is given; the default profile is default.
  • profiles — A mapping from profile names to profile definitions. A profile is a set of label definitions that can be selected when invoking apply. Each profile is defined by a mapping with the following fields:

    • defaults — A mapping of default label settings to apply to all labels in this profile. Any field that can be set on a label can be set here, other than name and rename-from. Settings set here override settings set in the top-level defaults mapping for the labels in this profile.

    • labels — A list of label specifications; each one is a mapping with the following fields:

      • name (required) — The name of the label. Leading & trailing whitespace will be trimmed; if the resulting string is empty, is it an error.

        • Note that GitHub treats label names case-insensitively; thus, the names "foo" and "Foo" refer to the same label. If you do or do not want your label names to enforce a specific casing, see the enforce-case option below.

        • It is an error if two or more labels in the same profile have the same name after case-folding.

      • color — The color to use for the label. Colors can be specified as a hex RGB string "#rrggbb" (with or without leading #) or as CSS color names. Alternatively, color may be set to a list of colors, in which case one of the colors will be picked at random when creating the label, and no change will be made to the label color when updating the label. An empty list is equivalent to ["#000000"].

        The default color value is a list of the default colors displayed when creating a new label in the GitHub web UI as of 2023-09-24.

      • description — The description to apply to the label. If this is not set, the description will be empty when creating the label, and no change will be made to the description when updating the label.

      • create (boolean; default: true) — If true, the label does not already exist, and no label specified in rename-from exists (See below), then the label will be created in GitHub.

      • update (boolean; default: true) — If true, the label exists (or a label specified in rename-from is being renamed to it), and the color and/or description of the pre-existing label differs from the value given in the configuration file, update the fields that differ.

      • enforce-case (boolean; default: true) — If true and the label exists but the name of the label in GitHub differs from the name in name when compared case-sensitively, update the label to use the casing specified in the configuration file.

      • rename-from — A list of label names; if the label given in the name field does not exist in the repository, but one of the labels in rename-from does, then the existing label will be renamed to the given name. If multiple labels in rename-from exist, an error will occur.

        • If the label given in name does exist and so do one or more labels in rename-from, a warning is emitted by default; see the on-rename-clash option below.

        • It is an error if a label includes its own name in rename-from.

        • It is an error if a label specified by a profile is also in the rename-from list of another label in the same profile.

        • It is an error if a label is listed in the rename-from fields of two or more labels in the same profile.

      • on-rename-clash — Specify what to do if the label exists and one or more labels listed in rename-from also exist. The possible values are:

        • "ignore" — Do nothing.
        • "warn" (default) — Emit a warning.
        • "error" — Fail with an error.

Example Configuration File

The following TOML configuration shows the default GitHub labels as of 2023-10-18, along with the default value of the color setting:

[defaults]
color = [
    "0052cc",
    "006b75",
    "0e8a16",
    "1d76db",
    "5319e7",
    "b60205",
    "bfd4f2",
    "bfdadc",
    "c2e0c6",
    "c5def5",
    "d4c5f9",
    "d93f0b",
    "e99695",
    "f9d0c4",
    "fbca04",
    "fef2c0",
]

[[profiles.default.labels]]
name = "bug"
color = "d73a4a"
description = "Something isn't working"

[[profiles.default.labels]]
name = "documentation"
color = "0075ca"
description = "Improvements or additions to documentation"

[[profiles.default.labels]]
name = "duplicate"
color = "cfd3d7"
description = "This issue or pull request already exists"

[[profiles.default.labels]]
name = "enhancement"
color = "a2eeef"
description = "New feature or request"

[[profiles.default.labels]]
name = "good first issue"
color = "7057ff"
description = "Good for newcomers"

[[profiles.default.labels]]
name = "help wanted"
color = "008672"
description = "Extra attention is needed"

[[profiles.default.labels]]
name = "invalid"
color = "e4e669"
description = "This doesn't seem right"

[[profiles.default.labels]]
name = "question"
color = "d876e3"
description = "Further information is requested"

[[profiles.default.labels]]
name = "wontfix"
color = "ffffff"
description = "This will not be worked on"

That same configuration, in YAML:

defaults:
  color:
    - "0052cc"
    - "006b75"
    - "0e8a16"
    - "1d76db"
    - "5319e7"
    - "b60205"
    - "bfd4f2"
    - "bfdadc"
    - "c2e0c6"
    - "c5def5"
    - "d4c5f9"
    - "d93f0b"
    - "e99695"
    - "f9d0c4"
    - "fbca04"
    - "fef2c0"

profiles:
  default:
    labels:
      - name: bug
        color: "d73a4a"
        description: Something isn't working

      - name: documentation
        color: "0075ca"
        description: Improvements or additions to documentation

      - name: duplicate
        color: "cfd3d7"
        description: This issue or pull request already exists

      - name: enhancement
        color: "a2eeef"
        description: New feature or request

      - name: good first issue
        color: "7057ff"
        description: Good for newcomers

      - name: help wanted
        color: "008672"
        description: Extra attention is needed

      - name: invalid
        color: "e4e669"
        description: This doesn't seem right

      - name: question
        color: "d876e3"
        description: Further information is requested

      - name: wontfix
        color: "ffffff"
        description: This will not be worked on

labelmaker's People

Contributors

dependabot[bot] avatar jwodder avatar renovate[bot] avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar

labelmaker's Issues

Support merging one label into another by relabeling issues

Support the following methods for merging labels:

  • Add one or more fields (TBD) to the configuration file for instructing the apply command to merge one label into another

  • Add a labelmaker merge <old-label> <new-label> command that does the following:

    • If <new-label> does not already exist in the repository, create it with a random color and empty description (Add options for setting these?)
    • Update all issues & PRs with <old-label> to have <new-label> instead
    • If a --no-delete option was not given, delete <old-label>

    Should this functionality be part of the make command instead?

Support alternative GitHub instances (GitHub Enterprise Server etc.)

labelmaker should gain an --api-url command-line option (defaulting to the value of the GITHUB_API_URL envvar, falling back to https://api.github.com) for specifying what GitHub API to interact with.

A preliminary implementation of this was removed in commit 6702d94.

Problems:

  • The only repository URLs (whether HTTP URLs specified on the command line or SSH URLs retrieved from a local Git repository's remote) that ghrepo can parse are those that refer to the main GitHub instance.

  • Given an API URL, how should the --hostname value to pass to gh auth token be determined?

    • It seems that, if a token is stored under example.com, then gh will return that token for all queries of subdomains under example.com.

As an alternative to --api-url, support could be added for specifying repositories in the form HOST/OWNER/REPO à la gh.

Support using a config file in `~/.config` if no config file is given on the command line

This would be a breaking change to apply, as its command-line usage would have to take the config file as an option rather than a non-option argument.

See https://stackoverflow.com/a/76341487/744178 regarding using a dynamic path (likely from dirs or similar) as the default config file path.

On the other hand, the whole motivation for this issue is so that I can run labelmaker without having to cd into the directory where I store my config file, but I'd still need a place to store my list of labelmaker-managed repositories, and moving the list to the config file after implementing #19 would just make it harder to automatically regenerate the list (unless I use toml_edit to preserve the formatting...), so maybe I'm doomed to always cd somewhere anyway.

Support profile inheritance

Setting profile.<name>.inherit = "other-profile-name" should cause all labels from the other profile to be included in this one.

Problem: How should differing profile defaults be handled — especially regarding defaulted settings on labels in the parent profile?

Add a command for creating or updating a single label

The command should basically create/update a single label in a single repository with all of the configuration specified as options on the command line.

  • If no rename-from values are given, the client doesn't even need to retrieve all labels in the repository; it can just check for the label being created/updated.

Support applying only one label entry from a config file

Should this be a feature of apply, make, or a new subcommand?

  • Idea: Give apply a multi-use -L <label>/--label <label> option that, if present, restricts apply to only creating the specified label(s).
    • Labels passed to --label have their create value ignored.

Support deleting labels

  • Give [profile.<name>] a delete: list[str] field naming labels to delete if present.

  • Give [profile.<name>] a delete-extra: bool field that, if true (default false) causes all labels in a repository that are not listed in the profile to be deleted

    • When doing this, the user should probably be asked to confirm each deletion unless a --force or --yes option was given on the command line.
      • All confirmations should be performed before executing anything, so that the user can quit in the middle without messing anything up.
  • Add a delete <label-name> ... subcommand?

Support specifying repositories and their profiles in the configuration file

apply and its configuration file should support the following uses:

  • Specifying the profile to use for a repository (when --profile isn't given on the command line) in the configuration file
  • Specifying a collection of repositories to operate on when some option (--all-repos?) is given on the command line

Possible configuration structure:

[repositories]
"owner/name" = "default"
"octocat/hello-world" = "custom"

With this structure, --all-repos operates exactly on those repos used as keys in [repositories], which means that, in order to include a repo that uses the default profile, the profile has to be given explicitly.

Perform more label name validation

GitHub rejects label names that are entirely composed of emoji characters (not to be confused with label names entirely composed of emoji shortcuts, which are accepted). labelmaker should reject these as well.

It's likely that GitHub enforces further checks, such as prohibiting control characters. Validate for these as well.


Observations so far:

  • GitHub seems to define an "emoji" as any character with the Emoji, Emoji_Component (except ASCII characters), or Extended_Pictographic property (See TR #51).
    • This includes regional indicator symbols (whether paired or alone) and emoji tag sequences for regional flags (e.g., 🏴󠁧󠁢󠁳󠁣󠁴󠁿 — U+1F3F4 U+E0067 U+E0062 U+E0073 U+E0063 U+E0074 U+E007F).
    • Emoji keycap sequences (e.g., 0️⃣ — U+0030 U+FE0F U+20E3) are allowed.
    • Text presentation sequences (e.g., ⌚︎ — U+231A U+FE0E) are not counted as emoji, but emoji presentation sequences (eg., ⌚️ — U+231A U+FE0F) are.
  • In addition to space characters, other forms of leading & trailing whitespace including LF, CR, VT, FF and TAB are stripped from label names.
  • An internal LF is converted to a space, but other internal whitespace characters are not.
  • Multiple consecutive spaces inside a name are allowed.
  • The following characters are allowed anywhere in label names and can be used as single-character names:
    • Non-whitespace C0 control characters
    • C1 control characters
    • DEL
    • /
    • ?
      • Side note: If a label with a ? is created, GitHub will not percent-escape the character when constructing the label's URL for use in API responses, and trying to operate on the this URL gives the wrong results.
    • backslash
    • %
    • U+00AD (soft hyphen; Cf)
    • U+0301 (combining acute accent; Mn)
    • U+0600 (Arabic number sign; Cf)
    • U+200C (zero width non-joiner; Cf)
    • U+200E (left-to-right mark; Cf)
    • U+200D (right-to-left mark; Cf)
    • U+2065 (<reserved>)
    • Private-use characters
  • The following characters are not allowed as single-character label names, but they can be used in longer names (and are not stripped from the ends of names):
    • U+00A0 (no-break space; Zs)
    • U+1680 (Ogham space mark; Zs)
    • U+2000 (en quad; Zs)
    • U+200D (zero width joiner; Cf; Emoji_Component)
    • U+2028 (line separator; Zl)
    • U+2029 (paragraph separator; Zp)
  • The following characters are not allowed anywhere in label names:
    • NUL
    • U+200B (zero-width space; Cf)
  • If a label is created with a name containing an unpaired high surrogate, the surrogate will be silently changed to a ?.
  • If a user tries to create a label with a name containing an unpaired low surrogate, a 500 error is returned.

Add a subcommand for checking a configuration file for validity

This should basically just load each profile and check there are no errors. It should also check that the default profile exists.

Problem: In order to provide a decent UX, the command will have to report all errors rather than just stopping at the first one.

Use a synchronous HTTP client

Using reqwest and async doesn't seem to be accomplishing anything in the code other than making things needlessly complicated. The code should use ureq for HTTP requests instead, and all async functionality should be made synchronous.

Reject invalid Description strings

GitHub requires label descriptions to be no more than 100 characters long. labelmaker should reject descriptions that do not satisfy this.

It's likely that GitHub enforces further checks, such as prohibiting newlines and/or control characters. Validate for these as well.


Observations:

  • Like label names, descriptions are normalized by having leading & trailing SP, LF, CR, TAB, FF, and VT character stripped, and internal LFs are converted to SP.
  • Leading & trailing NULs are also stripped from descriptions.
  • Unlike label names, there do not appear to be any restrictions on what characters are allowed in descriptions other than LF.

Renovate Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

  • [cargo] Autoupdate Cargo.lock

Detected dependencies

cargo
Cargo.toml
  • anstream 0.6.14
  • anstyle 1.0.7
  • anyhow 1.0.82
  • cfgfifo 0.2.0
  • clap 4.5.4
  • csscolorparser 0.7.0
  • derive_more 1.0.0
  • fern 0.6.2
  • gh-token 0.1.7
  • ghrepo 0.6.0
  • indenter 0.3.3
  • itertools 0.13.0
  • log 0.4.21
  • mime 0.3.17
  • parse_link_header 0.4.0
  • patharg 0.4.0
  • rand 0.8.5
  • reqwest 0.12.4
  • serde 1.0.200
  • serde_json 1.0.116
  • smartstring 1.0.1
  • thiserror 1.0.59
  • tokio 1.37.0
  • unicase 2.7.0
  • url 2.5.0
  • assert_matches 1.5.0
  • indoc 2.0.5
  • rand_chacha 0.3.1
  • rstest 0.22.0
github-actions
.github/workflows/test.yml
  • actions/checkout v4
  • Swatinem/rust-cache v2
  • actions/checkout v4
  • Swatinem/rust-cache v2
  • taiki-e/install-action v2
  • actions/checkout v4
  • Swatinem/rust-cache v2
  • taiki-e/install-action v2
  • codecov/codecov-action v4
  • actions/checkout v4
  • Swatinem/rust-cache v2

  • Check this box to trigger a request for Renovate to run again on this repository

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.