Skip to content

Repository files navigation

yeet

CIReleaseGo VersionOpenSSF ScorecardOpenSSF Best PracticesLicense

Automate releases on GitHub, GitLab, or Azure DevOps from your conventional commits.

With yeet, you can calculate the next semver or calver version, generate a changelog, open a release PR/MR, and publish the release after it merges. yeet ships as a single static binary with no runtime dependencies.

yeet is designed to run from CI on every push to a release branch. The local CLI is the setup and preview tool. Your CI workflow performs the recurring release work.

Quick start

1. Preview locally

For a GitHub repository, install yeet, export a token, generate the default config, and preview the release:

brew install monkescience/tap/yeet
export GITHUB_TOKEN=github_pat_xxx
yeet init
yeet release --dry-run

Use GITLAB_TOKEN or AZURE_DEVOPS_EXT_PAT for another provider. See Authentication for token permissions and CI variables.

yeet init creates only .yeet.yaml. The generated config is provider-neutral and auto-detects the public provider from the Git remote.

2. Automate it in CI

Add the matching release pipeline from CI setup. GitHub repositories normally use the GitHub Actions workflow. GitLab and Azure DevOps use the equivalent examples on that page.

Commit .yeet.yaml and the workflow. From then on, CI runs yeet release on pushes to the configured release branch.

3. Create the first release

Merge a feat, fix, or perf conventional commit into the release branch. CI opens the release PR/MR. Merge that release, then the next CI run creates the tag and provider release.

Install

Other installation options:

go install github.com/monkescience/yeet/cmd/yeet@v0.14.3 # x-yeet-version
docker run --rm ghcr.io/monkescience/yeet:v0.14.3 --help # x-yeet-version

On Windows, install with Scoop:

scoop bucket add monkescience https://github.com/monkescience/scoop-bucket
scoop install yeet

Shell completions are available through yeet completion bash|zsh|fish|powershell.

Why yeet

  • One release workflow across GitHub, GitLab, and Azure DevOps
  • Monorepo targets with combined or independent release PRs/MRs
  • Semver, calver, changelog, reviewer, and prerelease configuration
  • GitHub Enterprise, self-managed GitLab, and Azure DevOps Server support
  • One YAML file backed by a JSON schema

Command reference

CommandPurpose
yeet initCreate a .yeet.yaml configuration file
yeet releasePreview or perform the release workflow
yeet versionPrint build and version information
yeet completionGenerate shell completion scripts

Run yeet --help or yeet <command> --help for generated CLI help. The configuration guide covers common tasks, and yeet.schema.json is the complete field reference.

How it works

  1. Plan: yeet analyzes conventional commits and opens a labelled release PR/MR.
  2. Refresh: later runs update that open release instead of creating another one.
  3. Finalize: after merge, the next run creates the tag and provider release, then marks the PR/MR as tagged.

See Release PRs and MRs for lifecycle, labels, auto-merge, reviewers, release notes, and prerelease channels.

Verify a release

Archives and container images are signed with Sigstore and carry GitHub build provenance. Follow Artifact verification for the expected identities and copyable verification commands.

Documentation

TaskGuide
Add provider CICI setup
Configure a repository or monorepoConfiguration
Customize versions and changelogsVersioning and Changelog generation
Review or disable anonymous analyticsTelemetry
Recover from a failed releaseTroubleshooting
Migrate from release-pleaseMigration guide

Open the complete documentation index to find every task and advanced guide.

Feedback and contributions

About

Release automation for GitHub, GitLab, and Azure DevOps based on conventional commits

Topics

Resources

Contributing

Security policy

Stars

5 stars

Watchers

0 watching

Forks

Releases

Packages

Used by

Contributors

Languages