| name | grafana-plugin-release |
| description | Release the Grafana Cube datasource plugin end-to-end: babysit a feature PR until green and merge it, merge the release-please PR to publish a release, and run the CD workflow to deploy to Grafana Cloud. Use when the user mentions release, publish, ship, deploy the plugin, or babysit a PR. |
Grafana Plugin Release
Full release lifecycle for grafana/grafana-cube-datasource. Covers babysitting
a feature PR, cutting a release by merging the release-please PR, and deploying
via the CD workflow.
Version bump, CHANGELOG.md generation and tag push all happen in CI. A
release PR is maintained automatically by the Release Please workflow on
every push to main — to cut a release you just merge it. There are no local
git, npm or worktree commands to run. The only local credential needed is
gh auth to trigger workflows and merge PRs.
Phase 1 — Babysit & merge the feature PR
If the user provides a PR to babysit before releasing:
- Poll CI with
gh pr checks <PR> --repo grafana/grafana-cube-datasource
every 60–90s until all checks resolve.
- Triage any Bugbot or reviewer comments — fix what you agree with, explain
when you disagree.
- If a check fails, investigate the logs:
gh run view <run-id> --repo grafana/grafana-cube-datasource --log-failed
- PR titles must follow conventional commits (
feat:, fix:, chore:, …) —
the Conventional Commits check enforces this and the prefix decides the
CHANGELOG.md section the change is filed under. Fix the title with
gh pr edit <PR> --title "..." if it fails.
- Once green + mergeable, merge with squash and delete the remote branch:
gh pr merge <PR> --repo grafana/grafana-cube-datasource --squash --delete-branch
- Delete local branches for the merged PR and any predecessor PRs the user
mentions:
git branch -D <branch> ...
- Prune stale remote-tracking refs:
git fetch --prune origin
Phase 2 — Cut the release
Release-please maintains a "chore(main): release X.Y.Z" PR that is updated on
every push to main. It bumps package.json / package-lock.json and
prepends a CHANGELOG.md entry derived from conventional commits since the
last tag.
Bump rules (configured in release-please-config.json, with
bump-minor-pre-major + bump-patch-for-minor-pre-major set for 0.x):
- Any
feat!: or BREAKING CHANGE: → minor (would be major post-1.0)
- Any
feat: → patch (would be minor post-1.0)
- Only
fix: / chore: / docs: / ci: etc. → patch
Find the open release PR:
gh pr list --repo grafana/grafana-cube-datasource \
--label 'autorelease: pending' --json number,title,headRefName
If none exists, run gh workflow run release-please.yml --repo grafana/grafana-cube-datasource
to create one (it normally auto-runs on push to main).
Review the PR — confirm the proposed version and changelog match your intent.
If the version is wrong, either adjust commit messages on main (then push)
or use a Release-As: X.Y.Z footer in a follow-up commit.
Merge the release PR with squash:
gh pr merge <PR> --repo grafana/grafana-cube-datasource --squash --delete-branch
Merging tags vX.Y.Z, which triggers release.yml. The workflow builds
signed plugin artefacts, SHA checksums and provenance attestation, then
restores the matching CHANGELOG.md section as the release body, preserves
the attestation link added by build-plugin, and publishes the release as
latest.
Wait for the workflow to finish:
gh run list --workflow=release.yml --limit 1 \
--repo grafana/grafana-cube-datasource \
--json status,conclusion,displayTitle
If the workflow fails on the publish step, the release is left as a draft
with the build-plugin boilerplate body — fix forward by either rerunning the
workflow or manually publishing:
gh release edit v<VERSION> --repo grafana/grafana-cube-datasource --draft=false --latest
Phase 3 — CD deployment
The CD workflow (.github/workflows/publish.yaml) publishes to the Grafana
plugin catalog. It is triggered via workflow_dispatch. Each environment is
an independent run (they don't bundle each other).
Available environments: dev, ops, prod-canary, prod.
Default: deploy straight to prod. While the plugin is experimental and
moving fast, skip the staged rollout and go directly to prod:
gh workflow run publish.yaml --repo grafana/grafana-cube-datasource \
-f branch=main -f environment=prod
If the user wants a staged rollout instead, deploy through environments in
order (dev -> ops -> prod-canary -> prod), confirming each succeeds before
proceeding.
Poll the run with:
gh run list --workflow=publish.yaml --limit 1 \
--repo grafana/grafana-cube-datasource \
--json status,conclusion,displayTitle
Wait for "status": "completed" and "conclusion": "success".
Phase 4 — Internal post-publish steps
After the catalog publish completes, follow the internal post-publish runbook
to bump the plugin on the relevant Grafana Cloud instances and restart them.
Post-release
