chore: sync CRDs inside "/crds" folder

[jingyih]

The public documentation on installing alpha CRDs still references the legacy "/crds" folder. Let's ensure it stays up to date.

$ dev/tasks/sync-crds-folder.sh 1.127.0

[yuwenma]

/lgtm
/approve
/hold

Thanks for the change. I like the direction. There is actually a bigger issue we should fix to resolve the the alpha compatibility issue: The ./crds should be git-tag versioned together with the release version, otherwise users cannot apply a reliable ./crds

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yuwenma

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [yuwenma]

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

[jingyih]

Thanks for the change. I like the direction. There is actually a bigger issue we should fix to resolve the the alpha compatibility issue: The ./crds should be git-tag versioned together with the release version, otherwise users cannot apply a reliable ./crds

That makes sense. I was thinking we could run dev/tasks/sync-crds-folder.sh ${VERSION} as part of the release process.

[yuwenma]

cc @xiaoweim

[jingyih]

@xiaoweim
Do we still need to merge dev/tasks/sync-crds-folder.sh into the codebase, or have you already included it in the new release process?

/cc @yuwenma

[yuwenma]

Do we still need to merge dev/tasks/sync-crds-folder.sh into the codebase, or have you already included it in the new release process?

We can merge this script. But it would be called in an internal process right afterwe push the release git tag. And that will be automated

[xiaoweim]

Do we still need to merge dev/tasks/sync-crds-folder.sh into the codebase, or have you already included it in the new release process?

We can merge this script. But it would be called in an internal process _right after_we push the release git tag. And that will be automated

Yes I agree, we can merge it. But eventually it will be a step in an automated process. I think it would be better to incorporate it into the propose-tag step, so there will only be one PR before we push release tag @yuwenma.

[jingyih]

PR rebased. Dropped the second commit that ran the script to update the CRDs.

[xiaoweim]

/lgtm

[jingyih]

Rebased again, to pick up the fix for the broken HEAD.

[yuwenma]

/lgtm

[jingyih]

/hold cancel