As a contributor, I want to release continuously the Community Loki Operator on public community-managed OperatorHubs (Kubernetes/OpenShift), so that I can deliver fixes quicker to the upstream community.

Acceptance Criteria

1. The upstream container image pipeline is entirely based on GitHub actions.
2. The upstream container images continue to be available on DockerHub.
3. The new Loki Operator upstream release process is based on release-please as the rest of the Loki binaries.
4. The new Loki Operator upstream release process automates submitting PRs to the two OperatorHub instances.
5. The new Loki Operator upstream release process continues to tag operator releases as operator/vX.Y.Z on the public Grafana Loki repository.
6. The Loki Operator changelog is fully maintained by release-please based on conventional commits.
7. The PR checks include checking that each PR is following the conventional commits approach to ensure an up2date changelog upon release time.

Developer Notes

1. The present operator release process is currently maintained as a set of manual three-step approach:
   1. First create a prepare release PR (e.g. https://github.com/grafana/loki/pull/10996)
   2. Manual tag creation (e.g. https://github.com/grafana/loki/releases?q=operator%2F&expanded=true)
   3. Create operatorhub PRs after image publication with make operatorhub locally. (k8s-operatorhub, redhat-openshift-ecosystem)
   4. Take care that the operator Hub PRs pass the test gates and get merged by automation.
2. The present operator release builds on the assumption that upon tag creation DroneCI is building and publshing the operator releases on DockerHub: https://hub.docker.com/r/grafana/loki-operator/tags?page=1&name=0.

References

1. Loki Upstream Release Process: https://github.com/grafana/loki/issues/11625
2. Conventional Commits Spec: https://www.conventionalcommits.org/en/v1.0.0/