Summary
The default `create-plugin` template gives community developers a minimal `release.yml` and assumes manual `npm version patch && git push --follow-tags` for releases. That's a sensible default for the wide community audience.
But Grafana Labs plugin teams maintain a more opinionated stack on top — release-please for changelog/version automation, `build-plugin` with the platform bot for signed artifacts, `publish.yaml` for catalog deployment, etc. Each team rediscovers this independently when scaffolding a new plugin or migrating an existing one.
Proposal
Add a `--grafanista` (or similarly-named) flag to `create-plugin` that scaffolds the opinionated Grafana Labs stack alongside (or instead of) the basic template. Likely contents:
- `release-please.yml` workflow + `release-please-config.json` + `.release-please-manifest.json` (with bump-minor-pre-major / include-component-in-tag: false defaults that match how Grafana plugins are typically released)
- `release.yml` that auto-publishes the GitHub release with the matching CHANGELOG.md section as the body and `--latest` (the pattern recently developed in grafana/grafana-cube-datasource#323)
- Whatever else is part of the standard Grafanista stack (publish.yaml to catalog, etc.)
Why opt-in, not default
The opinionated stack relies on Grafana-internal infrastructure — most notably the `plugins-platform-bot-app` GitHub App, which is only installed on Grafana-org repos. The current default template is the right behavior for community developers who don't have access to that. (See also grafana/plugin-ci-workflows#713 where this scoping issue is discussed for one of the underlying actions.)
Open questions
- Which team owns this? `create-plugin` lives here in plugin-tools, but the release-please workflow, the platform bot, and the auto-publish step are owned by plugins-platform / catalog teams. Realistically this might end up with platform-productivity if neither plugins-platform nor plugin-tools picks it up.
- Should the flag scaffold additional opinionated bits beyond release-please (e.g. the publish-to-catalog flow, default CODEOWNERS, default Vault paths, etc.)?
- Is `--grafanista` the right surface, or would a separate `create-grafana-plugin` package / a config preset be a better fit?
Context
Came up while hardening `grafana/grafana-cube-datasource`'s release flow. Each Grafanista who scaffolds a plugin currently re-invents this stack — a non-trivial amount of duplicate effort that an opt-in default would absorb.
Summary
The default `create-plugin` template gives community developers a minimal `release.yml` and assumes manual `npm version patch && git push --follow-tags` for releases. That's a sensible default for the wide community audience.
But Grafana Labs plugin teams maintain a more opinionated stack on top — release-please for changelog/version automation, `build-plugin` with the platform bot for signed artifacts, `publish.yaml` for catalog deployment, etc. Each team rediscovers this independently when scaffolding a new plugin or migrating an existing one.
Proposal
Add a `--grafanista` (or similarly-named) flag to `create-plugin` that scaffolds the opinionated Grafana Labs stack alongside (or instead of) the basic template. Likely contents:
Why opt-in, not default
The opinionated stack relies on Grafana-internal infrastructure — most notably the `plugins-platform-bot-app` GitHub App, which is only installed on Grafana-org repos. The current default template is the right behavior for community developers who don't have access to that. (See also grafana/plugin-ci-workflows#713 where this scoping issue is discussed for one of the underlying actions.)
Open questions
Context
Came up while hardening `grafana/grafana-cube-datasource`'s release flow. Each Grafanista who scaffolds a plugin currently re-invents this stack — a non-trivial amount of duplicate effort that an opt-in default would absorb.