-
Notifications
You must be signed in to change notification settings - Fork 33
Open
Description
Hi,
I've been able to build and validate the operator on ppc64le. I've also published the build-script here. I'm trying to get the changes for adding ppc64le support merged. Since ppc64le is also a supported architecture in travis, I'm also aiming towards adding the ppc64le build to the travis job.
However, there are a few things where I am a bit confused and need some guidance:
- The image gcr.io/kubebuilder/kube-rbac-proxy:v0.5.0 which is used in
config/default/manager_auth_proxy_patch.yamlis not multi-arch. So, I need to usecarlosedp/kube-rbac-proxy:v0.5.0for ppc64le. But I can't find a clean way to accommodate this requirement to use different image based on current ARCH. - I see that this commit introduced a secrets detection capability with pre-commit hook configuration. Would this be enough to use the same ENV parameters as this in the travis job on my fork? Or do I have to make some extra configuration for the
secureparameters? shellcheck, which is needed forlinttarget, does not have ppc64le support yet. But I've been able to build it on ppc64le. I'm thinking of adding a script to build shellcheck inhackdirectory and reference that here for ppc64le by adding an ARCH check. Does that sound good? Is there a better way to do this?- About the yaml files which are published as assets on the release page, I'm not sure how the ppc64le specific yaml (e.g. apps_v1_deployment_ibmcloud-operator-controller-manager.yaml which uses
carlosedp/kube-rbac-proxy:v0.5.0instead ofgcr.io/kubebuilder/kube-rbac-proxy:v0.5.0) can be included there. Please advise.
Thank you!
Metadata
Metadata
Assignees
Labels
No labels