che
che copied to clipboard
eclipse-che
Add new fields in CheCluster CR to configure Git Services
Is your enhancement related to a problem? Please describe
We want to make it simpler for admin to configure Git services in Che (GitHub, Gitlab, BitBucket): it should not be necessary to look at Eclipse Che documentation.
This first issue is about the CheCluster CR update. There will be another issue dedicated to some new chectl parameters to configure git services.
Describe the solution you'd like
spec:
components
containerRegistry
+ gitServices:
+ github:
+ - secretName: github-oauth-config
+ gitlab:
+ - secretName: gitlab-oauth-config
+ endpoint: https://gitlab.com
+ bitbucket:
+ - secretName: bitbucket-oauth-config
+ endpoint: https://bitbucket.org
devEnvironments
networking
The oAuth App id/secret/private.key etc... should not be directly in the CR (no clear text passwords in the CR). The secret field of an oauthApp is the name of an existing Kubernetes Secret that includes the base64 encoded id and secret. That should be documented clearly in the CRD field to avoid that admins need to read Eclipse Che documentation.
We can implement Validating Webhook to check the CheCluster CR fields. I propose the following structure:
spec:
gitServices:
disabled: <bool>
github: <GitHub>
gitlab: <Gitlab>
Where GitHub and Gitlab are dedicated structures.
I see the several problems:
- Having
disabled=falseby default means that it would not be possible to deploy Eclipse Che via chectl without providing--che-operator-cr-patch-yamlflag to setdisalbed=trueif user doesn't have any git integration. - We have to be backward compatible and respect already existed git integration secrets on the cluster.
- Since we still support CheCluster API v1 (see https://github.com/eclipse/che/issues/21579), we need to add the similar fields there.
Ok @tolusha let's do that (git services are not required by default) but then we don't need the disabled: <bool> field anymore.
With your proposal, if the admin wants to configure both gitlab.com and gitlab on prem can he do something like this:
spec:
gitServices:
gitlab:
endpoint: gitlab.mycompany.com
secret: gitlabinternal-oauth-config
gitlab:
endpoint: gitlab.com
secret: gitlabdotcom-oauth-config
That won't be possible. I thought the only one configuration of gitlab service is possible on the cluster.
But anyway, we can move to arrays:
spec:
gitServices:
github: [<GitHub>]
gitlab: [<Gitlab>]
bitbucker: [<BitBucket>]
Ok. Yes we need to consider that use case as well so it's better to use lists.
