You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CRD changes to the types managed by the operator can’t easily be tested because the CRDs are installed by subctl. The version of subctl used notably in operator E2E isn’t rebuilt with the version of the operator being tested, so it doesn’t have the CRD changes (or RBAC etc.).
One possible fix for this (other than rebuilding subctl — which isn’t great because it means the operator project has knowledge of a specific dependent) would be to update the CRDs using the operator versions after initial deployment.
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further
activity occurs. Thank you for your contributions.
Talking about this on the scrub, it doesn't seem like this would do a lot to help with RBAC (which is what changes most frequently). The project where the RBAC is actually used, say Submariner's main repo, would still need a second PR after the RBAC changes to actually test them where they are used.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further
activity occurs. Thank you for your contributions.
CRD changes to the types managed by the operator can’t easily be tested because the CRDs are installed by
subctl
. The version ofsubctl
used notably in operator E2E isn’t rebuilt with the version of the operator being tested, so it doesn’t have the CRD changes (or RBAC etc.).One possible fix for this (other than rebuilding
subctl
— which isn’t great because it means the operator project has knowledge of a specific dependent) would be to update the CRDs using the operator versions after initial deployment.The text was updated successfully, but these errors were encountered: