Update the calico crd archive download url

[0ekk]

What type of PR is this?
/kind feature

What this PR does / why we need it:
As we know from #12077, currently obtaining the URL of the calico crd archive is unstable and may cause checksum failure after a period of time, so it is changed to the more recommended api access method of github.

Here is a script to get sha256 of them:

V=(3.29.2 3.29.1 3.29.0 3.28.3 3.28.2 3.28.1 3.28.0 3.27.5 3.27.4 3.27.3 3.27.2 3.27.1 3.27.0)
for v in ${V[@]}; do
  echo -n "$v: sha256:"
  wget -qO- https://api.github.com/repos/projectcalico/calico/tarball/v$v | sha256sum | awk '{print $1
}'
done

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

None

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 0ekk
Once this PR has been reviewed and has the lgtm label, please assign ant31 for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[0ekk]

/ok-to-test

[VannTen]

currently obtaining the URL of the calico crd archive is unstable and may cause checksum failure after a period of time

Do we have more background on that ? I haven't found anything related to the cause of that change.

[0ekk]

currently obtaining the URL of the calico crd archive is unstable and may cause checksum failure after a period of time

Do we have more background on that ? I haven't found anything related to the cause of that change.

Checksum of calico crd archive has been changed due to the github compression settings. More details please see the discussion on the comments of #12077

[VannTen]

Somehow I didn't see the end of the discussion.
Shouldn't we instead use the release-.tgz release artifacts provided by calico ?

https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives#stability-of-source-code-archives specifically mention for security purpose we should rely on releases.

[VannTen]

That would be a bit more costly for download, but on the plus side the binaries and containers images are included, so we might be able to save on that.

[0ekk]

If the cost of normal download time or retry time due to network instability when downloading large files can be ignored, then using the release-.tgz artifact can be a better choice indeed.

[VannTen]

The bulk of the size of the file seems to be container images (in tar format). With the correct adaptions they could be reused instead of downloaded separately, but I'm not sure how well the download role can handle that, though.

[ant31]

Somehow I didn't see the end of the discussion. Shouldn't we instead use the release-.tgz release artifacts provided by calico ?

https://docs.github.com/en/repositories/working-with-files/using-files/downloading-source-code-archives#stability-of-source-code-archives specifically mention for security purpose we should rely on releases.

Yes ideally we would use the release-xyz.tgz from the releases page.
The new api is not promising a stable checksum either, but to point always to the same commit when used with the commit sha.

I would go for the releasse-xyz.tgz if possible, not sure what is needed to change. Alternative could be to ask the calico team to release the tarball that we need.

[VannTen]

I think the current state (occasional change of the hash with github changing compression settings) is acceptable for now as long as we know about it. We should still go towards using the release-xyz.tgz artifacts, but OTOH I don't think it's worth it to change to the api endpoint in the meantime ; that way we save one "migration".

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.