Опишете задачата
Към всички skills

greptimedb-release

GreptimeTeam · Инструменти

Runbook for publishing a new GreptimeDB version (tag + GitHub release + docs release-note PR) on the upstream GreptimeTeam/greptimedb repo. Use when asked to "release" / "publish" a GreptimeDB version (e.g. v1.1.0, v1.0.3).

Оригинален текст · няма потвърден превод на български
Платформи: Не са посочениНиво: Не е посоченоВ индекса: 21.09.2026 г.Обновен в GitHub: 20.09.2026 г.

Теми: ai-agents · cloud-native · distributed-database · greptimedb · high-cardinality · logs · metrics · object-storage · observability · observability-database · opentelemetry · prometheus · promql · rust · self-hosted

Първо прочетете инструкцията.

Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.

Оригинален SKILL.md
GitHub хранилище
Звезди на репото
6697
Лиценз
Apache-2.0
Последна проверка на записа
21.09.2026 г.

Добавете в своя инструмент.

Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.

npx skills add GreptimeTeam/greptimedb

Страницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.

Откъс от SKILL.md

Началото на файла на автора, без превод.

GreptimeDB Release Runbook

Publish a formal GreptimeDB release on GreptimeTeam/greptimedb. Always operate against that repo (for gh, pass --repo GreptimeTeam/greptimedb). Changelog generation is a separate, involved task — use the greptimedb-release-note skill for it.

This whole flow touches public infrastructure. Confirm with the user before the outward-facing step (creating the release, which creates the tag and triggers CI).

Prerequisites & remote

  • Tools: gh (check with gh auth status) and git. Changelog generation additionally needs git cliff and Python — see the greptimedb-release-note skill.
  • Resolve the remote first. This runbook writes <remote> for the git remote pointing at GreptimeTeam/greptimedb; substitute your actual name (often upstream, sometimes origin on a direct clone): 
    git remote -v | grep -i 'GreptimeTeam/greptimedb' | awk '{print $1}' | head -1

0. Inputs: version and branch

  • Ask the user for the version to release (e.g. 1.1.0, 1.0.3) and, if needed, the branch.
  • Branch is inferred from version: MAJOR.MINOR → release/v<MAJOR>.<MINOR>.
    • v1.0.0 / v1.0.1 / v1.0.2 live on release/v1.0; v1.1.0 lives on release/v1.1.
    • Infer it, then double-check with the user.
  • New minor/major (X.Y.0) is cut from main. If release/vX.Y does not exist on the remote, offer to create it from the intended main commit (with the user's consent): git push <remote> <commit>:refs/heads/release/vX.Y.
  • Patch (X.Y.Z, Z>0) must use the existing release/vX.Y branch (it carries cherry-picked commits).
  • Check what exists on the remote: git ls-remote --heads <remote> 'release/*'.

1. Verify the Cargo version

The workspace version on the release branch must equal the version being released, or stop. Fetch the branch first, then read FETCH_HEAD directly — git fetch <remote> release/vX.Y only opportunistically updates the remote-tracking ref <remote>/release/vX.Y (and only when the remote has a matching configured refspec), so it may be missing or stale (e.g. a custom <remote>, or a branch just created in §0). Reading FETCH_HEAD always reflects the tip just fetched:

git fetch <remote> release/vX.Y
git show FETCH_HEAD:Cargo.toml | grep -A30 '\[workspace.package\]' | grep -m1 version

(For a fresh minor cut from main, <remote>/main and release/vX.Y are usually the same commit.)

Целият SKILL.md в GitHub