Cluster API operator is not accepting internal repository fetchconfig url

[rajgani]

What steps did you take and what happened:
[A clear and concise description on how to REPRODUCE the bug.]
Cluster API operator is not accepting internal repository fetchconfig url

• Deploy Cluster API Operator
• Try to apply Core Provider Custom Resource

kind: CoreProvider
metadata:
  name: cluster-api
  namespace: capi-system
spec:
  fetchConfig:
    url: https://example.com/stash/projects/E-C/repos/cluster-api/browse/core-components.yaml?at=development

What did you expect to happen:
We are trying to deploy Cluster API operator in an AirGap environment which do not have access to github.com or Gitlab.com, we see Cluster API Operator supports Airgap installations, however while deploying CoreProvider in capi-system namespace with an Internal repository url, it throws below error.

E0410 17:49:52.667842 1 controller.go:329] "msg"="Reconciler error" "error"="failed to create repo from provider url for provider \"cluster-api\": invalid provider url. Only GitHub and GitLab are supported for \"https\" schema" "CoreProvider"={"name":"cluster-api","namespace":"capi-system"} "controller"="coreprovider" "controllerGroup"="operator.cluster.x-k8s.io" "controllerKind"="CoreProvider" "name"="cluster-api" "namespace"="capi-system" "reconcileID"="e2a00b85-08ce-4796-854e-486c106519eb"

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Environment:

• Cluster-api-operator version: v0.9.1
• Cluster-api version: v1.6.3
• Minikube/KIND version:
• Kubernetes version: (use kubectl version): v1.24.17
• OS (e.g. from /etc/os-release): CentOS 7.9

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api-operator/labels?q=area for the list of labels]

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI Operator contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[furkatgofurov7]

@rajgani hey.

Have you tried using ConfigMap instead of specifying url: spec.fetchConfig.selector.matchLabels.provider-components
described in https://cluster-api-operator.sigs.k8s.io/03_topics/02_configuration/01_air-gapped-environtment.html#air-gapped-environment and that helps?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten