release

Automates graylog-cli releases by bumping versions, verifying Nix builds, tagging, and pushing git tags.

1|Updated Apr 22, 2026
One-click install
npx skills add https://github.com/NorceTech/graylog-cli --skill release-norcetech
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/NorceTech/graylog-cli/tree/main/.claude/skills/release
Command: npx skills add https://github.com/NorceTech/graylog-cli --skill release-norcetech

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Releasing a new version of graylog-cli involves many error-prone manual steps: choosing the next semantic version, keeping Cargo.toml and the git tag in sync, verifying the Nix build, and pushing the correct tag to trigger the GitHub Actions release workflow. This Skill codifies that entire procedure with safety checks so releases are consistent and mistakes like tagging off-main commits or mismatched versions are caught before publishing. ## Core Features & Use Cases - Version Determination: Computes the next patch, minor, or major version from the latest git tag, or accepts an explicit version, with explicit handling of prerelease suffixes. - Version Synchronization: Updates Cargo.toml, regenerates Cargo.lock, and verifies the version matches the intended tag (flake.nix derives its version automatically from Cargo.toml). - Build Verification: Runs the same Nix build used by CI (including the optional Windows cross-build) before any tag is created. - Safe Tagging and Push: Enforces a clean working tree, main-branch-only tagging, annotated tags, and post-push monitoring of the GitHub Release workflow. - Use Case: A maintainer wants to ship a bugfix release. They invoke the skill with "patch", and it walks through inspecting the repo state, bumping 0.1.0 to 0.1.1, verifying the Nix build, committing, tagging v0.1.1, pushing, and watching the release workflow build Linux, macOS, and Windows binaries. ## Quick Start Create a new patch release of graylog-cli, bumping the version, verifying the Nix build, tagging, and pushing the release.

Frequently Asked Questions about release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a new release of graylog-cli?

Invoke the release skill with patch, minor, major, or an explicit version. It inspects the repo state, bumps the version in Cargo.toml, regenerates Cargo.lock, verifies the Nix build, commits, creates an annotated v-prefixed tag, and pushes it to trigger the GitHub Actions release workflow.

How is the next release version number determined?

The skill reads the latest v* git tag sorted by version and increments it according to the requested bump: patch increments Z, minor increments Y and resets patch, major increments X and resets the rest. An explicit version can also be supplied, with any leading v stripped.

Do I need to update flake.nix when bumping the version?

No. flake.nix derives its version from Cargo.toml using builtins.fromTOML, so only Cargo.toml needs editing. Cargo.lock must be regenerated with cargo generate-lockfile so the Nix build stays consistent.

Why does the release workflow fail at the verify-main step?

The verify-main job fails when the tagged commit is not reachable from origin/main. Fix it by moving the release commit onto main, pushing main, recreating the tag on that commit, and pushing the tag again.

What happens if the release git tag already exists?

Published tags must never be overwritten. If the tag was already pushed, choose the next version instead. Only a tag that exists locally and was never pushed can be safely deleted and recreated.

Can I release from a dirty working tree or a feature branch?

No. The skill requires a clean working tree and the main branch before releasing. The GitHub Actions workflow rejects tags whose commits are not part of origin/main history.