Summary
The version check errors out when the submitted version is not greater than the latest published version on grafana.com:
error: Plugin version 0.3.16 is invalid.
detail: The submitted plugin version 0.3.16 is not greater than the latest published version 0.3.16 on grafana.com.
This is correct behavior for publish/submission-time validation. But when the CLI is used in CI to validate plugin archives on pull requests (a recommended practice), it guarantees failure for every PR of any healthy plugin: between releases, the repo version always equals the published one, and it can only become "greater" after the release PR merges. See also grafana/plugin-actions#342 — the package-plugin GitHub Action runs this check unconditionally, so all PR builds of such plugins fail.
Why this looks like a misfire in CI context
An unsigned archive (no MANIFEST.txt) cannot be a publish attempt — it is a PR/dev build by definition. Yet the check hard-fails there, while the adjacent unsigned plugin finding is correctly downgraded to a warning:
error: Plugin version 0.3.16 is invalid.
...
warning: unsigned plugin
detail: MANIFEST.txt file not found. ...
Suggested behavior
- If the archive is unsigned (no
MANIFEST.txt), emit the version-vs-catalog result as a warning instead of an error, or skip it entirely; or
- Introduce an explicit mode/flag for CI vs publish validation (e.g.
--mode=ci), where catalog-state checks are advisory.
Note the check is already disable-able via config file (analyzers.version.enabled: false), which we use — the remaining hazard is the default-on behavior for anyone wiring the CLI into PR CI, especially via the plugin-actions workflows which do not expose the config.
Environment
Summary
The
versioncheck errors out when the submitted version is not greater than the latest published version on grafana.com:This is correct behavior for publish/submission-time validation. But when the CLI is used in CI to validate plugin archives on pull requests (a recommended practice), it guarantees failure for every PR of any healthy plugin: between releases, the repo version always equals the published one, and it can only become "greater" after the release PR merges. See also grafana/plugin-actions#342 — the
package-pluginGitHub Action runs this check unconditionally, so all PR builds of such plugins fail.Why this looks like a misfire in CI context
An unsigned archive (no
MANIFEST.txt) cannot be a publish attempt — it is a PR/dev build by definition. Yet the check hard-fails there, while the adjacentunsigned pluginfinding is correctly downgraded to a warning:Suggested behavior
MANIFEST.txt), emit the version-vs-catalog result as a warning instead of an error, or skip it entirely; or--mode=ci), where catalog-state checks are advisory.Note the check is already disable-able via config file (
analyzers.version.enabled: false), which we use — the remaining hazard is the default-on behavior for anyone wiring the CLI into PR CI, especially via the plugin-actions workflows which do not expose the config.Environment
grafana/plugin-validator-cli:v0.49.1and@grafana/plugin-validator@latest(npx), 2026-09-18.