Re: operators and ci/cd
Daniel Messer
On a related point, given the way the sdk is laying down a skeleton project to be filled in, what is best practice for
a) Updating to be aligned with later versions of the SDK
- Since I had a 'simple' project I ended up cut/pasting the controller and definitions to go from 1.0.0 to 1.6.1 (as the steps became more complex)
- for 1.6.1 to 1.6.2 I looked at the code diff, and the brief reference in the release notes to image versions going forward .1, and did the same
b) Deciding what gets checked in
- Currently I am checking in most files from the built project, but am wondering what the appropriate mix of code gen and checkin is (which depends on the original question)--On Friday, 23 April 2021 at 09:42:39 UTC+1 Nigel Jones wrote:I've built a simple go operator (based on memcached) and have ideas/plan forthe capability I want to add.
However in addition I'd like to get a basic CI/CD process set up. Initially a simple compile, then ideally a test/deploy.
I'm using operator sdk 1.6.1 on macOS primarily, with code hosted in github. Whilst I am experimenting with the operator I am doing
- 'make generate' to ensure the go type definitions are up to date
- 'make manifests' to ensure the CRDs are up to date
- 'make install' to build the code
- 'make docker-build docker-push IMG=xxxx' to build the image
- 'make deploy IMG=xxxx' to deploy the operator
Firstly, to get compile validation I tried the first 3 steps in a github action, having made use of the setup_go action. However it failed with '/home/runner/work/egeria-k8s-operator/egeria-k8s-operator/bin/controller-gen: Exec format error' which made me realise that presumably the skeleton project contains architecture dependent code, and my primarily build environment is in ubuntu
Later I was thinking of either using 'make run' to ensure the operator at least launches ok, and perhaps build the image/deploy to a 'KIND" environment within the build pipeline - and run more tests there (already do this on another project)
So I felt it a good time to ask :
- what is best practice here?
- what do you do for build validation?
- how do you approach getting the right native code in place (if that is the issue)
- how are you automating testing of your operator in your pipeline?
Many thanks
Nigel (@planetf1 on github)
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/cdf86070-c650-4dba-88cf-5f0b0f28683fn%40googlegroups.com.
Product Manager Operator Framework & Quay
Red Hat OpenShift
Camila Macedo
I will try to share some detailed info, and I hope that helps you.
Pre-requirements
- To run make manifests, you need to have a controller-gen See (here[1]).
- Also, you will need to have kustomize[2]
- And then, to run make test[3], you will need to have the env test binaries[15].
So, you need to ensure that all requirements will be installed before. You can check here[13] how we set up the environment in the CI for SDK and here[14] how we do that in Kubebuilder.
Why do we use Kind?
In Kubebuilder and SDK, we use Kind to test the projects because it allows us to load the manager image that was built in the CI with `kind load docker-image --name`. So, instead of make docker-push you will use that. See here[4] for example. Then, I'd like to recommend you use that. Otherwise, your CI needs to be able to push and pull the image from the public registry.
Use Envtest
Regarding recommendations, I'd like to suggest you test the controllers with Envtest. It is described in the Best Practices section. See here[5] and then, you will see that it has a link for Testing your Operator project[6].
E2e options
Regarding e2e tests, you can do something that is done in Kubebuilder/SDK using Kubebuilder tests utils lib[7] and ginkgo[8]/gomega[9], which makes that significantly easier, allows debugging via an IDE, etc ...
You can check in the SDK, and Kubebuilder repos its examples to test the projects in the testdata. See here[10] and here[11].
Also, you can use the shell script as we did in the past; see an example[12] with the legacy layout for you to have a better idea.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/CAEQM%2BpNdpWPkTK-jAPPg8EmUwUvA3VqxZdEe60tPsTf5kMF9ZQ%40mail.gmail.com.