Implement scripts to release che-operator

[davidfestal]

Setup a reproducible way to test / release the operator on OperatorHub

Current state of Testing / Release process

Until now releasing the che operator is a totally manual thing. Though it was still somewhat easy for the operator code itself (build, tag and deploy docker image), it isn't easy at all, and very error-prone to manually build OLM-related yaml files and submit them in PR to the community-operators repository for each release we want to deploy to the OperatorHub, especially due to the fact that we cannot test the whole package before deploying it to the marketplace.

Detailed description

This issue defines what should be done to correctly and continuously test the Che Operator (including the OLM files and OperatorHub-based installation), and release it to the OperatorHub without risks.

This would be great if a decent minimal implementation of this purpose could be setup before Che 7 GA, to ensure a successful release to the marketplace.

The main purpose can be decomposed into several subtasks:

• Bring back the Che operator OLM and OperatorHub related YAML files (.csv, .package) into the che-operator repository for both the Openshift and the K8S cases,
• Allow maintaining the consistency between the basic operator deployment yaml files (operator.yaml, rile.yaml, etc...) and the OLM-related files (.csv, etc ...)
• Have a way to easily package the OLM-related files and push them to a distinct Quay.io namespace and application, so that can be installed and tested independently from the official OperatorHub marketplace,
• Allow this new way to test the operators in OLM to also test the nightly operator with nightly versions of the Che and Keycloak docker images,
• Allow deriving the files that should be included into the official OperatorHub (community-operators Repository) from the source CSV maintained our own che-operator repository,
• Provide scripts to:
  • build and push to Quay.io the night operator docker image,
  • build, tag and push to Quay.io a (pre-)release of the operator docker image,
  • manage the various OLM-related files and push them to appropriate testing Quay.io application repositories
  • Prepare the content of PRs on the community-operators repository, based on a given release of the OLM files hosted in our own che-operator repository

[dmytro-ndp]

There could Che CI or CRW CCI be used for this propose.

[davidfestal]

@dmytro-ndp It seems we would plan to use Eclipse CI for the Che operator, as discussed in these PR comments: eclipse-che/che-operator#45 (comment)
But the first step is definitely to add all the necessary bits in the che-operator repository in a conveniently structured way, and provide related scripts, before even thinking of automating it in a CI.

[tsmaeder]

This sounds like good and important work, but I have two questions:

1. Is this going to be done before end of this sprint?
2. Is there potential for this breaking anything or disrupting developement?

[davidfestal]

@tsmaeder

1. Is this going to be done before end of this sprint?

That's the idea yes. Maybe not a full automation of it (in CI I mean), but at least having the related files and scripts available in the repo, and a clear process documented about how to update / test / release the Operator OLM files.

2. Is there potential for this breaking anything or disrupting developement?

I don't see any: this issue is mainly about adding new files and scripts that were not in the repository previously, and formalizing / scripting / documenting processes that were purely manual and informal until now.

[davidfestal]

So what should I do to add it into the Endgame plan ?

[l0rd]

I confirm that this will be part of the endgame but the scope is only limited to what is needed to script a release of the che-operator, something that was done manually until now.

[ibuziuk]

@davidfestal I believe we can close this one and have a CI for che-operator as part of the separate issue #13951

[davidfestal]

@ibuziuk sure.