clusterctl init doesn't work when metadata is merged but release isn't published

[willie-yao]

/kind bug

[Before submitting an issue, have you checked the Troubleshooting Guide?]

What steps did you take and what happened:
According to the release instructions, we first merge the metadata for the release and then publish it. However, this ends up breaking clusterctl init between when we merge the metadata and before the release is actually published.

Running:

clusterctl init --infrastructure azure

Gives this error:

Error: failed to get provider components for the "azure" provider: failed to get repository client for the InfrastructureProvider with name azure: error creating the GitHub repository client: failed to get latest release: release not found for version v1.14.0, please retry later or set "GOPROXY=off" to get the current stable release: 404 Not Found

This also affects specifying a specific version when running clusterctl init, so nobody is able to initialize a management cluster during this period.

What did you expect to happen:
clusterctl init --infrastructure azure should always work.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[willie-yao]

Running the command with GOPROXY=off does fix things. I'm guessing this is the intended behavior, but if the user doesn't have anything cached and doing a fresh install of CAPZ, this would still be a problem. We should consider changing the order of operations in the release process.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[willie-yao]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[willie-yao]

/remove-lifecycle stale