Downgraded k8s libraries to fix spew of errors on pre 1.20 clusters

[istyf]

See puzzle/cert-manager-webhook-dnsimple@11fb703#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6
and puzzle/cert-manager-webhook-dnsimple#8 for details

[Identitry]

Hi @istyf!
As you can see the test failed...
The reason for this is that the build pipeline in Azure doesn't have access to secrets on pull requests. This is this is a public repository and anyone can make a pull request with malicious code to extract the secret if I would allow it access to secrets.

This is my first open source project on GitHub and my first with CI so I lack all the experience. For example my pipeline includes build to Docker hub and that could f**k up things up for people that uses the latest tag for their Kubernetes deployments so luckily the build failed even though I don't think anyone uses it yet except me and maybe you. :-).

Before I can merge this I need to rebuild the pipeline, make sure it builds first. I might also register a free LoopiaDomain account and add a cheap domain to it just for testing and then enable PR's access to the secrets.

Any advice, is this something you're experienced with and in that case maybe this can be moved off Azure Pipelines!?

[istyf]

Sorry for abandoning this PR for a while.

It seems to me that maybe your pipeline would benefit from being divided into smaller steps? A first step could be to just build the code and tag an image and then maybe have an extra release pipeline that runs more extensive tests. Setting up a dedicated domain for running end to end tests all the way to Loopias API on each PR seems a bit excessive to me.

Have you considered something like contract testing? It could be possible to abstract away Lets Encrypt and Loopia and have the tests assert that the Webhook behaves correctly without requiring access to any external services. Builds from a develop branch could use contract testing for quicker feedback, while release builds from the main branch could use a more complete setup with proper end to end testing and verification.

Pulling images into production using the latest tag is considered a bad practice, so if anyone would be doing that and a PR build ended up in their cluster it would be just what they asked for. ;)

[Identitry]

I'm sorry too, however I've started to rebuild the CI/CD pipeline on GitHub Actions that offer better security but currently I have some problems for the test to succeed and I have no clue why but I do hope I will soon :-).

I've chosen to keep the conformance test supplied by (and requested by) the cert-manager team but I'll run the more extensive test they supply on deploy that will be triggered from a tagged push event. Except for deploy to Docker Hub I might also use GitHub pages to act as Helm repository that makes deployment easier.

[Identitry]

Hi @istyf!
I have now made a lot of fixes and I included your downgrade of binaries...

Changelog (main changes):

• Subdomain is now deleted correctly.
• Helm-chart is published to GitHub pages
• CI/CD is now using GitHub Actions
• Downgraded k8s libraries to fix spew of errors on pre 1.20 clusters

Closing this PR since changes are already made.