Flake in operator-developer-e2e: potentially due to GitHub rate-limiting

[joelanford]

https://github.com/operator-framework/operator-controller/actions/runs/5871742974/job/15921834994?pr=336#step:4:484

Looks like the culprit is that we're trying to curl | sh for a kustomize binary install and we're getting rate-limited by GitHub

{ curl -Ss "[https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh](https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh/)" | bash -s -- 3.8.7 /home/runner/work/operator-controller/operator-controller/test/operator-framework-e2e/registry-operator/bin; }\nGithub rate-limiter failed the request. Either authenticate or wait a couple of minutes.

[tmshort]

It appears that the curl command comes from operator-sdk, which comes from kubebuilder. I found a change to operator-sdk that updates kubebuilder, which also appears to change the install of kustomize from using go get to curl. See: https://github.com/operator-framework/operator-sdk/blob/master/website/content/en/docs/upgrading-sdk-version/v1.21.0.md Which leads to: https://github.com/operator-framework/operator-sdk/pull/4863/files It appears we regressed from v3.0.0 to v3.0.0-alpha.0.0.20210503171920-2b857cb37698 But the latest operator-sdk uses kubebuilder/v3-v3.9.1, and that kubebuilder still curls kustomize

[joelanford]

If we're inheriting that from kubebuilder -> operator-sdk, I guess it makes sense for us to NOT try to work around that.

After all, that's sort of the point of this e2e: does the soup to nuts work without requiring users to make tweaks.

[tmshort]

We could try to add a manual retry, but yeah, we really can't change it.

[tmshort]

We could try to add a manual retry, but yeah, we really can't change it.

This line would need to be retried if we wanted a fix before operator-sdk updates.

[m1kola]

Job log is no longer available. Also we now install kustomize via bingo. It looks like obsolete, so I'm closing this.