# github-release-tool

**Repository Path**: mirrors_syncthing/github-release-tool

## Basic Information

- **Project Name**: github-release-tool
- **Description**: There are tools many like it but this one is mine
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-02-10
- **Last Updated**: 2026-01-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# GitHub Release Tool

## Workflow, General Idea

Commit code, close issues. At release time, decide on a new version. Gather
issues closed since that release and collect them into a milestone with the
new release version.

From this milestone, generate change log and releases (multiple, if there
are candidates). When done, close the milestone.

## Pre-requisites

- You use the issue labels `bug` and `enhancement`.
- You close issues by `fixes #1234` style annotations in the commit subject.
- You use semver-style versions.
- You have your GitHub token in the `GITHUB_TOKEN` env var when executing this command.

## Usage

```
usage: grt --owner=OWNER --repo=REPO [<flags>] <command> [<args> ...]

Flags:
  --help         Show context-sensitive help (also try --help-long and --help-man).
  --owner=OWNER  Owner name (or set GRT_OWNER)
  --repo=REPO    Repository name (or set GRT_REPO)

Commands:
  help [<command>...]
    Show help.


  milestone --from=TAG/COMMIT [<flags>] <milestone>
    Collect resolved issues into milestone

    --dry-run               Don't do it, just report what would be done
    --from=TAG/COMMIT       Start tag/commit
    --to="HEAD"             End tag/commit
    --skip-label=LABEL ...  Issue labels to skip

  changelog [<milestone>]
    Show changelog for milestone


  release [<flags>] <milestone>
    Create release from milestone

    --dry-run  Don't do it, just report what would be done
    --to=NAME  Release name/version (default is milestone name)
```

## Examples

### Create a new milestone

Let's say we released v0.14.40 a while back, it's now time to release a
candidate for v0.14.41. We start by gathering closed issues into the
milestone.

```
$ grt milestone --from=v0.14.40 v0.14.41
```

This lists all the commits since `v0.14.40` (the tag), looks for GitHub "...
fixes #1234" annotations in the commit subject, and grabs those issues. It
creates the milestone `v0.14.41` and adds them to it.

This means the milestone now contains the issues that should go into the
changelog, and the issues themselves show the release they will be in as
their milestone. This is useful for any user looking at the issue.

### View the changelog for a milestone

```
$ grt changelog v0.14.41
```

This gathers the issues in the mentioned milestone and prints a changelog,
grouped for bugs, enhancements and other issues. Use this for your tag
message, actual changelog file, or whatever.

### Release a version based on a milestone

It's time to put out a release candidate, `v0.14.41-rc.1`.

```
$ grt release v0.14.41 --to=v0.14.41-rc.1
```

This creates the `v0.14.41-rc.1` release, sets the description to the
changelog from above. Since the version is different from the milestone
name, the release is marked as a pre-release and the milestone is not closed.

At some later date, we release the tested version.

```
$ grt release v0.14.41
```

The same thing as above happens, except the milestone is closed and the
release is not marked pre-release.