clusterctl only considers 30 github releases

[killianmuldoon]

When clusterctl looks for releases for providers it looks up the https://api.github.com/repos/kubernetes-sigs/cluster-api/releases endpoint. This endpoint by default only lists the most recent 30 releases. Even if an earlier release does exist clusterctl will not find it if it's not in the most recent 30 releases.

The current impact of this is that clusterctl v0.4.X and clusterctl v0.3.X no longer work to initialize providers. A workaround is to pull the provider yamls manually and put them in a local clusterctl repository.

v0.4.X and v0.3.X of Cluster API are out of date so there is no need to update those older versions to fix this bug. This should be fixed in supported versions of Cluster API as we don't control the number of releases done by providers and different approaches e.g. many published pre-releases, could result in an older supported version not being installable.

The API call should be able to look through subsequent pages of results in order to find older valid tags. Note: This should also be checked for the gitlab API to see if it suffers from a similar limitation.

/kind bug
/area clusterctl

[abhay-krishna]

I faced this issue when emulating the ListReleases call here and not the GetReleaseByTag call here which does indeed fetch an older tagged release, as far back as v0.2.6. While testing using curl, adding a per_page search query to the /releases API endpoint ensured that upto 100 versions are listed, the default being 30. Go-github supports the per_page input through the ListOptions parameter to the ListReleases call, is adding that a valid solution?

[killianmuldoon]

IMO instead of picking an arbitrary limit of per_page for the call it would be best if the client could go through each page of releases so it finds the latest in the series even if it's not in the first X results. You're right that the api by default returns 30 items - not sure how I counted to 60 earlier 😅

[abhay-krishna]

Yeah that would indeed be best. In most paginated API calls, one of the fields in the response is a token which, when passed into a subsequent call to the same API, fetches the next set of items. And the calls are made to the API until the token field is either empty or same as that returned from a previous call. This is prevalent in several production APIs such as those provided by AWS. I don't think GitHub does that, so what we can do is retrieve results page by page, appending the results to a list, until the results array is an empty list.

[abhay-krishna]

Was able to test with this code snippet that the approach of combing through the pages one by one and pooling releases together works, fetches all 119 releases it can find. Would you like me to open a PR for this?

Code:

// capi-releases.go
package main

import (
	"fmt"
	"context"
	"os"

	"github.com/google/go-github/v48/github"
	"golang.org/x/oauth2"
)

func main() {
	httpTokenSource := oauth2.StaticTokenSource(
		&oauth2.Token{AccessToken: os.Getenv("GITHUB_TOKEN")},
	)
	httpClient := oauth2.NewClient(context.TODO(), httpTokenSource)
	client := github.NewClient(httpClient)
	allReleases := []*github.RepositoryRelease{}

	// Get the first page of releases
	releases, response, err := client.Repositories.ListReleases(context.TODO(), "kubernetes-sigs", "cluster-api", nil)
	if err != nil {
		fmt.Printf("Error listing github releases: %v\n", err)
		os.Exit(1)
	}
	allReleases = append(allReleases, releases...)

	// Github API Response includes a LastPage field for paginated calls
	// https://github.com/google/go-github/blob/master/github/github.go#L536-L546
	lastPage := response.LastPage

	// From the second page to the last page, fetch all releases, passing in the page number to the ListOptions argument
	for pageNum := 2; pageNum <= lastPage; pageNum++ {
		releases, response, err = client.Repositories.ListReleases(context.TODO(), "kubernetes-sigs", "cluster-api", &github.ListOptions{Page: pageNum})
		if err != nil {
			fmt.Printf("Error listing github releases: %v\n", err)
			os.Exit(1)
		}
		allReleases = append(allReleases, releases...)
	}

	fmt.Println(len(allReleases))
}

Output:

go run capi-releases.go
119

[abhay-krishna]

@killianmuldoon Opened a PR, let me know what you think!

[killianmuldoon]

Just to add some clarity and context: This is only impactful when the latest version of a release series is not in the first 30 results in the github releases. Currently the returned releases are all from the v1beta1 release series. This would only impact a v1beta1 release after 30 v1beta2 releases. This means versions like 1.0.0 are available today even though it was released before v0.4.8

[fabriziopandini]

/triage accepted
/assign @abhay-krishna