Artifacts not promoted for the `ecr-credential-provider`

[hakman]

I was looking for laster release artifacts for the ecr-credential-provider. Based on what's in artifacts/manifests/k8s-staging-provider-aws, there should be artifacts for v1.33.0 (#8062):
https://github.com/kubernetes/k8s.io/tree/main/artifacts/manifests/k8s-staging-provider-aws

Though this doesn't match what's available in the bucket for promoted artifacts:

> gsutil ls gs://k8s-artifacts-prod/binaries/cloud-provider-aws/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.26.0/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.26.1/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.27.0/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.27.1/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.27.3/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.27.4/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.28.2/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.28.3/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.28.9/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.29.0/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.29.6/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.30.3/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.30.8/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.31.0/
gs://k8s-artifacts-prod/binaries/cloud-provider-aws/v1.31.7/

CC @cartermckinnon @dims

[cartermckinnon]

Thanks @hakman, I’ll dig into it.

[BenTheElder]

We are aiming to move away from promoting to GCS vs github. Only a few repos are using it, and it's less sustainable for us.

[BenTheElder]

x-ref #7584

[cartermckinnon]

@BenTheElder sounds good to me, this promo process has been pretty annoying for us. Is there a doc or project you can point me to that's using the recommended approach?

[BenTheElder]

I don't think we have a particular "official recommended approach" yet unlike the container images (... which also have very different consumption and distribution properties).
The subprojects vary widely in how they're doing this and what all they're releasing.

For example in kind, I've just made sure that the CLI binary artifact is built reproducibly (so it doesn't matter if they're built on my laptop or anywhere else ... verifiable same bits), and I drag the binaries to the release page in the github UI when tagging a release.

For a standalone go binary that's pretty easy to accomplish and then there's a lot of flexibility in how you manage populating them IMHO. I currently use these options but I'm not sure if they're all necessary still, go has improved over time:
https://github.com/kubernetes-sigs/kind/blob/5d59e3be91212cd98737be6bf38230dbf20819dc/Makefile#L62 -trimpath -ldflags="-buildid=" (the other flags are version metadata).

A few projects are using https://goreleaser.com/, e.g.
https://github.com/kubernetes/release/blob/3c696bde3c0cf41421ba18269641fc819b3b2501/.github/workflows/release.yml

https://github.com/kubernetes-sigs/kubebuilder/blob/9623a8b467fe3cc5dd715e9c15db743836d3bcee/.github/workflows/release.yml

but I can't speak directly to that yet. I have heard positive things indirectly.
The fact that SIG release is using it for their tools (though not k/k's much more complex release) speaks well to that approach. Some of the release engineering group may be able to comment. https://github.com/kubernetes/community/blob/master/sig-release/README.md#release-engineering

I plan to discuss with @xmudrii when he's back from vacation as a release engineering team member + sig k8s infra TL.