The committers listed above are authorized under a signed CLA.

• ✅ login: gregfurman (167030b, b7ced58, 3baf235)

This issue is currently awaiting triage.

If cloud-provider-aws contributors 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.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign m00nf1sh for approval by writing /assign @m00nf1sh in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Hi @gregfurman. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

We will most likely remove the automated release creation. The asset can be uploaded as part of the release procedure post pushing to staging (thus ensuring that the uploaded asset also match the asset in the prod bucket).

/hold

We will most likely remove the automated release creation. The asset can be uploaded as part of the release procedure post pushing to staging (thus ensuring that the uploaded asset also match the asset in the prod bucket).

Any reason not to push the binary for now until a final decision / approach is made? The lack of available binary combined with the ECR credential helper being the officially documented kubernetes example is confusing a lot of people if you look on the official slack.

The decision has been made, just not implemented. What needs to happen is the artifact promotion job needs to be fixed.

PR needs rebase.

For the tag:
https://github.com/kubernetes/cloud-provider-aws/releases/tag/v1.27.0

the ecr-credential-provider is here:
https://artifacts.k8s.io/binaries/cloud-provider-aws/v1.27.0/linux/amd64/ecr-credential-provider-linux-amd64

you can see the other versions/binaries using the gcp console:
https://console.cloud.google.com/storage/browser/k8s-artifacts-prod/binaries/cloud-provider-aws

Seems like this can be closed, @gregfurman @olemarkus do you disagree?

@dims Is that actually the process? It doesn't seem some of the 1.28 releases are in that GCS bucket.

I think we've missed artifact promotion for the last round of releases. I'll get a PR open. The container images are live, though.

Did you open a PR for artifact promotion @cartermckinnon? I only found this after 10 mins of searching on this repo.

Yet another example of how the documentation for this provider is severely lacking and really needs to be prioritized for update and cleanup.

@et304383 awesome thanks for volunteering!

@et304383 awesome thanks for volunteering!

No, this is AWS' job. They (you) are a multi-billion dollar company that provides this essential provider with little to no documentation or instructions. That is not in line with the quality we have come to expect from AWS.

Apologies! my bad, please note the this is a kubernetes community repository.