How to set GITHUB_TOKEN during clusterctl init command

[moluzhui]

What steps did you take and what happened:
[A clear and concise description on how to REPRODUCE the bug.]
When executing clusterctl init --infrastructure docker -v 5, the following error is returned

Error: failed to read "cert-manager.yaml" from provider's repository "cert-manager": failed to download files from GitHub release v1.5.3: rate limit for github api has been reached. Please wait one hour or get a personal API tokens a assign it to the GITHUB_TOKEN environment variable

Then I applied for Personal Access Tokens of repo scope in Github Developer Settings

Finally, run export GITHUB_TOKEN=<my_token>. Init command is executed again, but the above error is still reported

my_token has the same form type as gph_xxxxx

What did you expect to happen:
Break rate limit and create the content you need

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

Environment:

• Cluster-api version: v1.0.2
• Minikube/KIND version: kind v0.11.1 go1.16.9 linux/amd64
• Kubernetes version: (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.12", GitCommit:"7cd5e9086de8ae25d6a1514d0c87bac67ca4a481", GitTreeState:"archive", BuildDate:"2021-05-25T03:24:12Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-21T23:01:33Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}
• OS (e.g. from /etc/os-release):
  Centos 7

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[sbueringer]

ghp_ should be fine. You don't need a specific scope, but it shouldn't hurt. Maybe you have to export the token with quotes "" because there is some special character in it? (but based on my github token there shouldn't be one)

I'm just using something like the following (that is of course not my actual token :)):

export GITHUB_TOKEN=ghp_65adfadsf234r234dsvyhjklgfdg3g35gsdgfds

P.S. It should be absolutely unrelated to your issue, but you have to use clusterctl v1.0.4. cert-manager was moved to a new repo and we fixed clusterctl accordingly in v1.0.4 (https://github.com/kubernetes-sigs/cluster-api/releases/tag/v1.0.4)
(There are workarounds, but using the newer clusterctl is the easiest way)

[moluzhui]

I updated to v1.0.4 version. clusterctl init --infrastructure docker -v 5 can install cert-manager directly. However, GITHUB_TOKEN is not currently used, and will be tested when the rate limit appears in the future.

Note: I am currently using this form of yours

export GITHUB_TOKEN=ghp_xxxxx

[sbueringer]

@moluzhui So should we close the issue for now?

[cmoulliard]

Is it documented somewhere that we must update CAPA to at least 1.0.4 to avoid this issue that we have with 1.0.1, 1.0.2 ... ? @sbueringer

NOTE: The issue is still there even using 1.0.4

clusterctl version
clusterctl version: &version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.4", GitCommit:"e52c151433b43e2ccfbf7a1b95cd085810c207d3", GitTreeState:"clean", BuildDate:"2022-02-02T15:51:57Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

clusterctl init -i docker
Fetching providers
Error: failed to get provider components for the "cluster-api" provider: failed to get repository client for the CoreProvider with name cluster-api: error creating the GitHub repository client: failed to get GitHub latest version: failed to get repository versions: failed to get repository versions: rate limit for github api has been reached. Please wait one hour or get a personal API tokens a assign it to the GITHUB_TOKEN environment variable
[snowdrop@k122-centos7 ~]$

and the workaround is to pass its own GITHUB_TOKEN

export GITHUB_TOKEN=ghp_xxxxxxxxxxx
[snowdrop@k122-centos7 ~]$ clusterctl init -i docker -v 6
No default config file available
Fetching providers
Fetching File="core-components.yaml" Provider="cluster-api" Type="CoreProvider" Version="v1.1.3"
Fetching File="bootstrap-components.yaml" Provider="kubeadm" Type="BootstrapProvider" Version="v1.1.3"
Fetching File="control-plane-components.yaml" Provider="kubeadm" Type="ControlPlaneProvider" Version="v1.1.3"
Fetching File="infrastructure-components-development.yaml" Provider="docker" Type="InfrastructureProvider" Version="v1.1.3"
Fetching File="metadata.yaml" Provider="cluster-api" Type="CoreProvider" Version="v1.1.3"
Fetching File="metadata.yaml" Provider="kubeadm" Type="BootstrapProvider" Version="v1.1.3"
Fetching File="metadata.yaml" Provider="kubeadm" Type="ControlPlaneProvider" Version="v1.1.3"
Fetching File="metadata.yaml" Provider="docker" Type="InfrastructureProvider" Version="v1.1.3"
Creating Namespace="cert-manager-test"
Installing cert-manager Version="v1.5.3"
Fetching File="cert-manager.yaml" Provider="cert-manager" Type="" Version="v1.5.3"
Creating Namespace="cert-manager"
Creating CustomResourceDefinition="certificaterequests.cert-manager.io"

[sbueringer]

This is the expected behavior at this time. For discussions about potential alternative implementations please see: #3982