[Bug]: kubectl-cnpg 1.29.1 cannot generate 1.28.2/1.28.3 manifests although 1.28.1 works

[marcschaeferger]

Is there an existing issue already for this bug?

• I have searched for an existing issue, and could not find anything. I believe this is a new bug.

I have read the troubleshooting guide

• I have read the troubleshooting guide and I think this is a new bug.

I am running a supported version of CloudNativePG

• I have read the troubleshooting guide and I think this is a new bug.

Contact Details

info@marcschaeferger.de

Version

1.29 (latest patch)

What version of Kubernetes are you using?

1.34

What is your Kubernetes environment?

Other

How did you install the operator?

YAML manifest

What happened?

What happened?

I am using the kubectl-cnpg plugin version 1.29.1, installed via Krew.

kubectl cnpg version

Output:

Build: {Version:1.29.1 Commit:a4060c152 Date:2026-05-08}

I wanted to generate an operator installation manifest for a previous supported CloudNativePG operator version with a custom namespace and replica count.

According to the documentation for kubectl cnpg install generate --version, it should be possible to specify a minor version like 1.28, and the plugin should generate the latest patch version for that minor version.

However, the following commands fail:

kubectl cnpg install generate --version 1.28.3 --replicas 2 -n operators
kubectl cnpg install generate --version 1.28.3 -n operators
kubectl cnpg install generate --version 1.28.3

kubectl cnpg install generate --version 1.28.2 --replicas 2 -n operators
kubectl cnpg install generate --version 1.28.2 -n operators
kubectl cnpg install generate --version 1.28.2

Example error:

Error: release version 1.28.3 not found
Error: exit status 1

Generating the manifest for the current plugin version works:

kubectl cnpg install generate --version 1.29.1 --replicas 2 -n operators

Generating the manifest for 1.28.1 also works:

kubectl cnpg install generate --version 1.28.1 --replicas 2 -n operators

This is confusing because 1.28.2 and 1.28.3 are newer patch versions in the same 1.28 minor line than 1.28.1.

I also tried switching the plugin version via Krew. When using the 1.28.2 plugin version, generating 1.28.2 works. However, there is no 1.28.3 plugin version via krew (see https://github.com/kubernetes-sigs/krew-index/commits/843b1dc7d9e6d6300c2819f2961e88bcb38df5bc/plugins/cnpg.yaml ) so there seems to be no way to generate/install the 1.28.3 operator manifest with custom namespace and replicas using the Krew-installed kubectl-cnpg CLI.

Screenshot:

Cluster resource

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[dosubot]

Hi @marcschaeferger! I'm Dosu and I'm helping the CloudNativePG team.

This is a confirmed gap in how the kubectl cnpg plugin handles release manifests. The plugin doesn't fetch manifests from a remote URL at runtime — instead, it embeds them directly into the binary at compile time using Go's embed package [1]. When you request a version, it looks for a file named cnpg-<version>.yaml in the embedded filesystem, and returns "release version not found" if it doesn't exist [2].

The root cause is that the manifests for 1.28.2 and 1.28.3 were added to their respective release branches via PRs [3] [4], but were never merged back to main. Since the plugin is built from main, it only includes manifests present there — which for the 1.28.x line stops at cnpg-1.28.1.yaml [5].

Workaround: You can download the operator manifests directly from the GitHub releases page for v1.28.2 or v1.28.3, rather than generating them via the plugin. You'll need to manually adjust the namespace and replica count in the downloaded YAML.

This looks like a release process issue where patch release manifests from release branches need to be synced back to main so they're available in subsequent plugin builds.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[marcschaeferger]

@dosu.

Thanks, that matches what I am seeing.

I am aware of the direct download workaround, but this broke our automation. The workaround is also not very convenient for our use case, because we intentionally use kubectl cnpg install generate to produce one ready-to-commit manifest with the required namespace and replica count already applied.

Downloading the release YAML directly means we need additional patching/post-processing via Kustomize, yq, or another custom step just to get the same result the CLI normally provides.

The problem with that is that these patches can become fragile over time. For example, a newer CNPG version could add another container, another image field, a new namespace reference, or change/add fields that also need to be patched or remove them. Then the Kustomize patches or custom post-processing logic would need to be adjusted again.

There are several reasons in this specific case why having one final generated file with all required changes already applied is important for us. This was always very convenient with CNPG and a handful of other projects/Operator (we need this only for Operators)

Just to be clear: I do not have anything against Kustomize or patching in general. I use base + environment overlays in many other cases daily, and in most GitOps setups this is exactly what I prefer. But for this specific operator installation manifest, the CLI-generated single file is the better and more stable and required workflow for us. If not availible we create such a workflow ourself.

For me the main issue is not only that 1.28.2 / 1.28.3 are missing, but that this makes the CLI behavior depend on which manifests were synced back to main. That is hard to detect upfront and can break automation unexpectedly.

It would be very helpful if patch release manifests from supported release branches were synced back to main, or if the CLI could clearly list/validate the versions available in the embedded manifest set.

[marcschaeferger]

And '1.28.2' Manifest worked with the '1.28.2' CLI... But no Krew Plugin release for '1.28.3'

So that there was no krew release for '1.28.3' is another/seperate issue in my view.