feat: builds helm chart

[AlexsJones]

This PR is in two parts

First part This PR is to implement the helm chart and simplify the generation of that chart

The second part will be to serve the chart from the repo

After this is accepted I will add the code to convert this repo into a helm repo which will enable

helm repo add ofo https://github.com/open-feature/open-feature-operator
helm upgrade --install release ofo/open-feature-operator

for now you can use

#clone the git repo 
cd chart
helm upgrade ofo . --install

[codecov-commenter]

Codecov Report

Merging #137 (7dc9b1e) into main (80bcfba) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##            main    #137   +/-   ##
=====================================
  Coverage   0.00%   0.00%           
=====================================
  Files          1       1           
  Lines        122     122           
=====================================
  Misses       122     122           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[toddbaert]

for now you can use

#clone the git repo 
cd chart
helm upgrade --install . ofo 

That gets me Error: release name is invalid: . on helm v3.10.0.

I think you mean helm upgrade ofo . --install,

However, the ofo-chart-controller-manager stays in a ContainerCreating state indefinitely, and streaming the logs fails. Maybe I've missed a step?

[AlexsJones]

Fixed, this was due to missing CRD's and wrong image

[AlexsJones]

[toddbaert]

I'll test this again in a couple hours when I'm back at my PC!

[toddbaert]

Thanks!

This all works for me provided I install cert-manager first, otherwise I'm missing objects.

Error: unable to build kubernetes objects from release manifest: [resource mapping not found for name: "ofo-serving-cert" namespace: "" from "": no matches for kind "Certificate" in version "cert-manager.io/v1"

I'm know this is a pre-requisite, and not a new one, but I'm still a bit confused if this hard dependency is a good idea. Could the cert manager requirement prevent adoption if an admin has some alternative policy or solution for generating self-signed certs? Is it more or less standard for operators that accept requests to require cert-manager? I'm not truly not sure, so I defer once more to your expertise, @AlexsJones !

[toddbaert]

@AlexsJones I pushed a commit to add a couple files to the release please extra-files member, which tells release please to look for the x-release-please annotations in those files. Hope you don't mind.

[AlexsJones]

nfused if this hard dependency is a good idea. Could the cert manager requirement prevent adoption if an admin has some alternative policy or

For posterity, the reason it needs the certificate is for mTLS between the api-server and the webhook.
It's something we do need, it doesn't have to be cert-manager, but given they just got brought into CNCF incubation I think we're backing the right horse

[AlexsJones]

Please review when you have a spare moment, I added to the readme @toddbaert
Also I will squash all these commits, I was too lazy to rebase so did a skip

[toddbaert]

Readme changes look good to me!

Sorry for that missing comma!