Update operator version in deployment.yaml

[Links2004]

Update operator version in deployment.yaml to get the correct version on install via kustomize.

[CLAassistant]

All committers have signed the CLA.

[hubeadmin]

Nice catch, thanks @Links2004 !

[NissesSenap]

Hey @Links2004
So unless I screwed up the release yaml the kustomize config should get the correct version automatically

grafana-operator/.github/workflows/release.yaml

Line 52 in d3508c0

kustomize edit set image ghcr.io/${{ github.repository }}=${{ env.GHCR_REPO }}:${{ github.ref_name }}

So if you download the kustomize artifact it should contain the correct version https://github.com/grafana/grafana-operator/pkgs/container/kustomize%2Fgrafana-operator/156599061?tag=v5.6.0
You can see how to downloda the artifacts using flux here https://grafana.github.io/grafana-operator/blog/2023/03/29/install-grafana-operator-using-flux-and-kustomize/, sadly this feature isn't available in kustomize or ArgoCD.

I don't see an issue with this PR, but it's also not a prat of our normal prepartions for a new release, since it already automated, so I see that this will happen again.

FYI @HubertStefanski

[Links2004]

my current gitops process uses kustomize + argocd.

basiclly it comes down to render everything with kustomize and commit it to git for argocd to pick it up.

e.g.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - github.com/grafana/grafana-operator/deploy/kustomize/overlays/cluster_scoped/?ref=v5.6.0

namespace: monitoring

having flux as only options sounds not optimal to me, lets hope that kustomize or argocd gets support soon.
I totally understand hat the release automation does not commit changes to the git itself and that this is good.

Maybe it's worth checking out a release as tar.gz too (add to the release as Assets)

based on https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/resource/

URL specifications should follow the hashicorp URL format

and hashicorp URL / go-getter has a archive option.
https://github.com/hashicorp/go-getter?tab=readme-ov-file#unarchiving

but this need to be tested, had only a quick read of the docs.

in case someone needs the patch that I had as workaround in the future:

patches:
  - target:
      kind: Deployment
      name: grafana-operator-controller-manager
    patch: |-
      - op: replace
        path: "/spec/template/spec/containers/0/image"
        value: ghcr.io/grafana/grafana-operator:v5.6.0

upsteam argo proposals:
https://github.com/argoproj/argo-cd/blob/master/docs/proposals/native-oci-support.md

and may the docu needs an update since this part here will run in the same problems with the version that I had.

grafana-operator/docs/docs/installation/kustomize.md

Lines 24 to 52 in d3508c0

	## Install
	Two overlays are provided, for namespace scoped and cluster scoped installation.
	For more information look at our [documentation](https://grafana-operator.github.io/grafana-operator/docs/grafana/#where-should-the-operator-look-for-grafana-resources).
	This will install the operator in the grafana namespace.
	```shell
	kubectl create -k deploy/overlays/cluster_scoped
	```
	for a namespace scoped installation
	```shell
	kubectl create -k deploy/overlays/namespace_scoped
	```
	### Patching grafana-operator
	When you want to path the grafana operator instead of using `kubectl apply` you need to use `kubectl replace`.
	Else you will get the following error `invalid: metadata.annotations: Too long: must have at most 262144 bytes`.
	For example
	```shell
	kubectl replace -k deploy/overlays/cluster_scoped
	```
	For more information how `kubectl replace` works we recommend reading this [blog](https://blog.atomist.com/kubernetes-apply-replace-patch/).

[NissesSenap]

Trust me @Links2004 I want nothing else then have ArgoCD actually support OCI in a good way, and sadly I'm stuck with ArgoCD as well, so right now I use helm for my deployment.

I'm open for other suggestions on how to provide Kustomize, as long as I don't manually have to update it in yaml manually.
Currently, I assume that Kustomize users will path the image just as you have done in the example. But it would be nice if this is documented (happy to take a PR).