-
Notifications
You must be signed in to change notification settings - Fork 1.5k
no-jira: Fix verify capi manifests script #9752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no-jira: Fix verify capi manifests script #9752
Conversation
Nutanix was crashing the script due to: - using an unavailable git ref (fixed by adding git fetch) - dependency issues: kustomize & controller-gen not found
These are the correct versions of the CRDs, according to the verify-capi-manifests script.
|
@patrickdillon: This pull request explicitly references no jira issue. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
tthvo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
Looks good! I just have a small nit and a question.
|
|
||
|
|
||
| # Install `controller-gen` & `kustomize`, which are needed by nutanix, if not present |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought, usually, these tools are version-pinned and downloaded automatically on their side. Let me see if I can contribute upstream.
Also, took this chance to nit pick an extra newline haha
| # Install `controller-gen` & `kustomize`, which are needed by nutanix, if not present | |
| # Install `controller-gen` & `kustomize`, which are needed by nutanix, if not present |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully, someone will take a look soon haha 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this would definitely be better--thanks for doing it right. I tried to ping some upstream reviewers on your PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @patrickdillon ! From comments upstream, they "did" similarly but moved to dev-box. So it's not great to make them switch again so I closed it 😓
So, currently this way is best we can do :D I am only concerned as it is using "latest"...
hack/verify-capi-manifests.sh
Outdated
| clone_path="$(mktemp -d)" | ||
| git clone "${repo_origin}" "${clone_path}" | ||
| pushd "${clone_path}" | ||
| git fetch "${repo_origin}" "${revision}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the concerns I observed: there are small diffs in infra manifest between the released assets and the generated ones in the same commit.
One example: #9704 (review). Or similarly, if I run the ./hack/verify-capi-manifests.sh again in this PR here (released v1.17.5 azure-infra manifest). I see:
diff --git a/data/data/cluster-api/azure-infrastructure-components.yaml b/data/data/cluster-api/azure-infrastructure-components.yaml
index 215de54e78..abca06bac3 100644
--- a/data/data/cluster-api/azure-infrastructure-components.yaml
+++ b/data/data/cluster-api/azure-infrastructure-components.yaml
@@ -80694,7 +80694,7 @@ stringData:
AZURE_SUBSCRIPTION_ID: ""
AZURE_SYNC_PERIOD: ${AZURE_SYNC_PERIOD:=""}
AZURE_TENANT_ID: ""
- AZURE_USER_AGENT_SUFFIX: cluster-api-provider-azure/v1.17.5
+ AZURE_USER_AGENT_SUFFIX: cluster-api-provider-azure/main
type: Opaque
---
apiVersion: v1
@@ -80980,8 +80980,8 @@ spec:
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- image: registry.k8s.io/cluster-api-azure/cluster-api-azure-controller:v1.17.5
- imagePullPolicy: IfNotPresent
+ image: gcr.io/k8s-staging-cluster-api-azure/cluster-api-azure-controller:main
+ imagePullPolicy: Always
livenessProbe:
httpGet:
path: /healthzI guess it does not matter much. But one idea is, for this script, to first find the released assets. If any, use that. If not, generate from code (maybe future improvement). WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickdillon I have a sketch of the idea above here: patrickdillon#2 (i.e. against this PR branch) if you'd like to have a quick look 😃
One of the benefits I can see is the shorter time to run the script (i.e. time ./hack/verify-capi-manifests.sh):
Before: 4m12.324s
After: 2m29.181s (with patrickdillon#2)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated: #9752 (comment) is added before CAPZ PR was merged. Though, I guess the question for checking released assets first is still valid?
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tthvo The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This improvement includes trying out the released assets first if any. In case that fails (i.e. not a version, or non-existing asset URL), fall back to generate from pinned revision.
|
/hold Adding a hold as a safety precaution. The upstream PR should merge and a new CRD should be regenerated either off of master or when a release puts one out (where the PR is included 😄 ) In regards to |
|
The current version of this pr has been breaking because the nutanix gitref is not actually merged (it is pointing to a pr). #9855 should unblock this. |
|
PR needs rebase. DetailsInstructions 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. |
|
@patrickdillon: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
/remove-lifecycle stale |
|
/close in favor of #10212 |
|
@patrickdillon: Closed this PR. DetailsIn response to this:
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. |
The verify-capi-manifests script was failing on nutanix, which referenced an individual commit--not a release. Fixed that by adding
git fetchand scripting some dependency management.Also included fixup of mismatched CRDs.