Split server configs into different confimap

api/v1/gitremote_types.go

@@ -30,13 +30,16 @@ type GitRemoteSpec struct {
 	GitBaseDomainFQDN string `json:"gitBaseDomainFQDN"`
 
 	// +optional
-	CustomGitProviderConfigRef corev1.ObjectReference `json:"customGitProviderConfigRef,omitempty"`
+	CustomGitServerConfigRef corev1.ObjectReference `json:"customGitServerConfigRef,omitempty"`
 
 	// +optional
 	TestAuthentication bool `json:"testAuthentication,omitempty"`
+
+	// +optional
+	InsecureSkipTlsVerify bool `json:"insecureSkipTlsVerify,omitempty"`
 }
 
-type GitProviderConfiguration struct {
+type GitServerConfiguration struct {
 	// +optional
 	Inherited bool `json:"inherited,omitempty" yaml:"inherited,omitempty"`
 	//+ optional
@@ -91,7 +94,7 @@ type GitRemoteStatus struct {
 	SecretBoundStatus SecretBoundStatus `json:"secretBoundStatus,omitempty"`
 
 	// +optional
-	GitProviderConfiguration GitProviderConfiguration `json:"gitProviderConfiguration,omitempty"`
+	GitServerConfiguration GitServerConfiguration `json:"gitServerConfiguration,omitempty"`
 }
 
 //+kubebuilder:object:root=true

chart/0.0.1/templates/config/bitbucket-configuration.yaml

@@ -0,0 +1,6 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: bitbucket.org
+data:
+  authenticationEndpoint: https://api.bitbucket.org/2.0/user

chart/0.0.1/templates/config/github-configuration.yaml

@@ -0,0 +1,6 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: github.com
+data:
+  authenticationEndpoint: https://api.github.com/user

chart/0.0.1/templates/config/gitlab-configuration.yaml

@@ -0,0 +1,6 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: gitlab.com
+data:
+  authenticationEndpoint: https://gitlab.com/api/v4/user

config/crd/bases/kgio.dams.kgio_gitremotes.yaml

@@ -39,9 +39,22 @@ spec:
           spec:
             description: GitRemoteSpec defines the desired state of GitRemote
             properties:
-              customGitProviderConfigRef:
+              customGitServerConfigRef:
                 description: |-
-                  Reference to a ConfigMap to configuration the behavior of the GitRemote connexion with the distant server
+                  ObjectReference contains enough information to let you inspect or modify the referred object.
+                  ---
+                  New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.
+                   1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.
+                   2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular
+                      restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".
+                      Those cannot be well described when embedded.
+                   3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.
+                   4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity
+                      during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple
+                      and the version of the actual struct is irrelevant.
+                   5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type
+                      will affect numerous schemas.  Don't make new APIs embed an underspecified API type they do not control.
+
 
                   Instead of using this type, create a locally provided and used type that is well-focused on your reference.
                   For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .
@@ -91,6 +104,8 @@ spec:
                 type: string
               gitBaseDomainFQDN:
                 type: string
+              insecureSkipTlsVerify:
+                type: boolean
               secretRef:
                 description: |-
                   SecretReference represents a Secret Reference. It has enough information to retrieve secret
@@ -123,7 +138,7 @@ spec:
                   status:
                     type: string
                 type: object
-              gitProviderConfiguration:
+              gitServerConfiguration:
                 properties:
                   authenticationEndpoint:
                     type: string

config/crd/bases/kgio.dams.kgio_resourcesinterceptors.yaml

@@ -43,7 +43,20 @@ spec:
               authorizedUsers:
                 items:
                   description: |-
-                    Reference to GitUserBinding objects
+                    ObjectReference contains enough information to let you inspect or modify the referred object.
+                    ---
+                    New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.
+                     1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.
+                     2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular
+                        restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".
+                        Those cannot be well described when embedded.
+                     3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.
+                     4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity
+                        during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple
+                        and the version of the actual struct is irrelevant.
+                     5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type
+                        will affect numerous schemas.  Don't make new APIs embed an underspecified API type they do not control.
+
 
                     Instead of using this type, create a locally provided and used type that is well-focused on your reference.
                     For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 .
@@ -134,7 +147,19 @@ spec:
                 type: string
               defaultUserBind:
                 description: |-
-                  Reference to a GitUserBinding. If set, this git user will be use to push the resources.
+                  ObjectReference contains enough information to let you inspect or modify the referred object.
+                  ---
+                  New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs.
+                   1. Ignored fields.  It includes many fields which are not generally honored.  For instance, ResourceVersion and FieldPath are both very rarely valid in actual usage.
+                   2. Invalid usage help.  It is impossible to add specific help for individual usage.  In most embedded usages, there are particular
+                      restrictions like, "must refer only to types A and B" or "UID not honored" or "name must be restricted".
+                      Those cannot be well described when embedded.
+                   3. Inconsistent validation.  Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will happen.
+                   4. The fields are both imprecise and overly precise.  Kind is not a precise mapping to a URL. This can produce ambiguity
+                      during interpretation and require a REST mapping.  In most cases, the dependency is on the group,resource tuple
+                      and the version of the actual struct is irrelevant.
+                   5. We cannot easily change it.  Because this type is embedded in many locations, updates to this type
+                      will affect numerous schemas.  Don't make new APIs embed an underspecified API type they do not control.
 
 
                   Instead of using this type, create a locally provided and used type that is well-focused on your reference.

internal/controller/git_pusher.go

@@ -29,7 +29,7 @@ type GitPusher struct {
 	gitEmail             string
 	gitToken             string
 	operation            admissionv1.Operation
-	remoteConfiguration  kgiov1.GitProviderConfiguration
+	remoteConfiguration  kgiov1.GitServerConfiguration
 }
 
 type GitPushResponse struct {