Cut the tags correctly from this repo and adopt best practices

[upodroid]

@cheftako @YifeiZhuang @mmamczur @bowei

The tags are not cut correctly for this repo.

 mahamed  Mac  ~  Desktop  Git  cloud-provider-gcp   master  2✔  4✎  3+  1  USAGE  $  git describe --tags --always --dirty
ccm/v34.0.0-17-g55db278bf-dirty
 mahamed  Mac  ~  Desktop  Git  cloud-provider-gcp   master  2✔  4✎  3+  1  $  git tag -l
auth-provider-gcp/v0.0.1
auth-provider-gcp/v0.0.2
auth-provider-gcp/v0.1.0
ccm/v0.0.1
ccm/v22.0.0
ccm/v22.1.0
ccm/v23.0.0
ccm/v24.0.0
ccm/v25.0.0
ccm/v25.2.0
ccm/v25.3.0
ccm/v25.5.0
ccm/v26.0.0
ccm/v26.0.1
ccm/v26.0.2
ccm/v26.0.3
ccm/v26.0.4
ccm/v26.15.0

Can we reset the tags and cut them correctly? Maybe cut the tags to follow the kubernetes tags, so v1.34.4 instead of ccm/v34.4.0 or if you really need to keep the current semver version, cut v34.4.0

Also, we need to have proper releases on GitHub, as many projects and end users depend on the contents of this repo. Look at #433(almost 3y ago), #879, #289(we do publish images but not in a timely manner). 1st party projects such as Kubernetes CI, kops, Cluster API, etc

We should be releasing the cloud provider like this: https://github.com/kubernetes-sigs/cloud-provider-azure/releases, https://github.com/kubernetes-sigs/cloud-provider-kind, proper release on GitHub, binaries in GitHub and images in registry.k8s.io.

Also, the way we generate the binaries is wrong:

 mahamed  Mac  ~  1  $  gsutil ls gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64 | tail
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251103-ccmv34.0.0-4-g4bc9861a
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251103-ccmv34.1.0
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251106-ccmv34.0.0-8-g433973ac
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251106-ccmv34.1.0-2-g3a17595a
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251113-ccmv34.0.0-11-g25e7d167
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251124-ccmv34.0.0-13-ga4cfad1b
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251125-ccmv34.0.0-15-gc5cb3fa0
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251203-ccmv34.0.0-17-g55db278b
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251203-ccmv34.1.0-4-gffb6ba2d
gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/linux-amd64/v20251203-ccmv34.1.0-6-gbe9a8bb4

The file structure should be like this:

gs://k8s-staging-cloud-provider-gcp/gke-gcloud-auth-plugin/v34.1.0-6-gbe9a8bb4/linux/amd64/gke-gcloud-auth-plugin

Then we can copy them to services like artifacts.k8s.io based on the leading version.

[k8s-ci-robot]

This issue is currently awaiting triage.

If the repository mantainers determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[YifeiZhuang]

Can we reset the tags and cut them correctly? Maybe cut the tags to follow the kubernetes tags, so v1.34.4 instead of ccm/v34.4.0 or if you really need to keep the current semver version, cut v34.4.0

Removing the ccm/ prefix requires changing GKE build pipeline configuration which also depends on this repo, so there will be extra steps. It might also impact the OSS image push pipeline. But should be doable. We need to prioritize it among other issues in the release processes. Ref release instruction.

We should be releasing the cloud provider like this: https://github.com/kubernetes-sigs/cloud-provider-azure/releases, https://github.com/kubernetes-sigs/cloud-provider-kind, proper release on GitHub, binaries in GitHub and images in registry.k8s.io.

The cloud-provider-azure cloud-provider-kind does not have much in common, e.g.cloud-provider-kind releases on main while azure one have release branches, semver are different.
CCM tags has been cut about each month in the last 6 months. The OSS image was also fixed due to various issues.

$ docker images registry.k8s.io/cloud-provider-gcp/cloud-controller-manager
REPOSITORY                                                    TAG       IMAGE ID       CREATED         SIZE
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v34.1.0   466a60efa952   4 weeks ago     148MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v34.0.0   dcf19eccba51   2 months ago    148MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v33.1.1   836316334d7b   5 months ago    139MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v32.2.2   5684d8d81528   9 months ago    135MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v30.0.0   7b6bd928ceeb   19 months ago   93.6MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v29.0.0   14a804195160   21 months ago   131MB
registry.k8s.io/cloud-provider-gcp/cloud-controller-manager   v26.2.4   ef12f9640ce0   2 years ago     115MB

Thanks for creating the issue. I also hate many of the release process steps. Feel free to comment about what can be improved.

[upodroid]

Thank you for responding.

Removing the ccm/ prefix requires changing GKE build pipeline configuration which also depends on this repo, so there will be extra steps. It might also impact the OSS image push pipeline. But should be doable. We need to prioritise it among other issues in the release processes. Ref release instruction.

Hopefully it's a trivial change, but please prioritise it. Does that include changing from v34.1.0 to v1.34.1? (You'll have a major problem when Kubernetes 2.y.z comes out, and you have conflicting git tags. Also, images can never be unpublished from registry.k8s.io)

Regarding the images, the ask is to publish them at the same time you cut the releases. I promoted 34.1.0 when I couldn't find it several weeks after k8s 1.34 was released, and v33.1.1 was promoted by someone else who doesn't work on this repo. ref.

From my perspective as a community maintainer, the priorities should be:

1. Cut the tags correctly and fix the downstream pipelines.
2. I opened a PR to fix the binary releases. Let's have them merged. I'm looking to host them at artifacts.k8s.io, as end users shouldn't be fetching them from the staging bucket.
3. https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository. I can help you with this.
4. Have images released at registry.k8s.io on the same day the tags are cut, and releases are built. It takes a few minutes.
5. Remove Bazel or at least upgrade it to v8/v7.
6. Regarding cluster/* aka kubeup jobs. I suggest you get remove it as you don't need it. I'm working on a similar initiative to replace the kubernetes/kubernetes equivalents with kops jobs. We already have a Kops job in the repository that uses a Kops cluster to test CCM changes.

I understand that you work at Google and focus on GKE, but this is a community project, and many open source projects in the Kubernetes org and beyond expect this repo to be well-maintained, released correctly and promptly.

• https://github.com/kubernetes/kops
• https://github.com/kubernetes-sigs/cluster-api-provider-gcp
• https://github.com/kubernetes-sigs/kubespray

[elmiko]

i echo what @upodroid is requesting here. i would like to see a future where all the sig-owned cloud-provider repos have a consistency about them. i think this will make it easier to attract contributors, and easier for the sig maintainers to work in different repositories.

at a recent sig cloud provider meeting we talked about the versions in this repo, i know @cheftako has some thoughts about this, but i would like to get things to a state where this repo is consistent with the other sig owned repos.

Remove Bazel or at least upgrade it to v8/v7.

this has been brought up several times at the sig meeting, i know @cheftako has done some work here and also @justinsb has #916 open. i'm hopeful we'll see a makefile in here soon.

[aojea]

We are mixing some things here, we want to move to a better place but we need to be organized and strategic about this, and not jump into conclusions too fast.

This repo hosted and still has different components, that is why there are prefixes on the tags, it was the only reasonable way at that time to be able to move forward without breaking things.

Golang modules and semver is a different topic, and we should be careful on how we do the changes to the tags because it has a large blast radious, so I like to see a proposal first before doing any change analyzing pros and cons

[upodroid]

I want to start with easy wins:

• Have the binaries built correctly. I have an open PR that creates new Bazel targets for the correct approach(same as Kubernetes and everyone else)
• Get GitHub releases built and the binaries added to it.
• remove prefixes from tags. I understand this affects GKE pipelines, but you really should be building everything on new tags.

Trickier topics that we should explore later.

• Amending semver tags

[aojea]

There are no need to remove tags, we can tag any version we want and we can have all sort of tags.

If the problem is the binary destination as in https://github.com/kubernetes/cloud-provider-gcp/pull/930/files#r2606718481 then is a tooling problem not a tagging problem

Let me understand the real problem, that AFAIK is the publishing of the binaries with predictive names so ecosystem can consume it, and the work into solving that, that is a simple thing to solve

[aojea]

/assign @aojea

I talked with @upodroid offline, what we need right now is a way to publish official binaries the OSS community and ecosystem can consume;

We agree on a path forward that is:

• Makefile that builds platform binaries for each binary in the repo (independent of bazel)
• cloudbuild.yaml will use this makefile to publish this binaries to the official bucket
• prow job config will only kick on a specific tag format version vX.Y.Z

Downstream teams can still use bazel and the existing tagging.
OSS teams can use current prow automation, and in addition to the downstream tag prefixed with ccm/ we add a new tag with the new OSS format vX.Y.X

[elmiko]

We agree on a path forward that is:

• Makefile that builds platform binaries for each binary in the repo (independent of bazel)
• cloudbuild.yaml will use this makefile to publish this binaries to the official bucket
• prow job config will only kick on a specific tag format version vX.Y.Z

thanks for the attention on this @aojea , i think what you are proposing makes good sense to me. also, i agree about not rushing in to any changes. i'm not looking to upset the apple cart here, but i think it will be good to get all our cloud-providers into similar shapes.