clientID is empty

[nikoChen-I755695]

Describe the bug
We are using Composition to deploy the BTP Kyma runtime. However, we encountered an issue where the Kyma creation failed with the error: "clientID must not be empty." The relevant code is provided below. I have verified that the clientID has been correctly input through the Composition data transfer.https://github.tools.sap/rgm/co-pipeline-action-core/blob/feature-development/infrastructure/charts/templates/kymaruntime/kyma-compositions.yaml

Tested with Provider Version
crossplane:
version: 1.18.0
providers:
- name: btp
version: 1.0.2
- name: kubernetes
version: 0.15.0
- name: ias
version: 0.2.0
- name: vault
version: 1.0.0
- name: btp-account
version: 0.7.6
- name: argocd
version: 0.9.1
To Reproduce
Steps to reproduce the behavior:

Expected behavior
Successful creation of kyma environment

Screenshots

Additional context

[JayChanggithub]

Hi Colleagues,

In collaboration with Niko, the issue has been posted. Please refer to the full context below. We ensured that the clientID was transferred via the composition field and is visible within the forProvider manifest. However, the status shows the clientID as empty. We're unsure what happened and would like clarification on the correct setup.

k get kymaenvironment.environment.btp.orchestrate.cloud.sap k-sre-slow-us21-co -o yaml

spec:
  cloudManagementRef:
    name: k-sre-slow-us21-co
  cloudManagementSecret: k-sre-slow-us21-co-cis-local
  cloudManagementSecretNamespace: default
  cloudManagementSubaccountGuid: 2dbb3308-71c6-4b1b-bdbf-9e83ccc4136a
  deletionPolicy: Delete
  forProvider:
    parameters:
      administrators:
      - [email protected]
      - [email protected]
      - [email protected]
      - [email protected]
      - [email protected]
      - [email protected]
      - [email protected]
      autoScalerMax: 3
      autoScalerMin: 3
      machineType: Standard_D8s_v5
      oidc:
        clientID: a7ff089c-5f56-48e8-9e1d-7ad0dc17ceaa
        groupsClaim: groups
        issuerURL: https://devexpdev.accounts.ondemand.com/
        signingAlgs:
        - RS256
        usernameClaim: email
        usernamePrefix: '-'
      region: eastus
    planName: azure
  managementPolicies:
  - '*'
  providerConfigRef:
    name: account-provider-config
  subaccountGuid: 2dbb3308-71c6-4b1b-bdbf-9e83ccc4136a
  subaccountRef:
    name: k-sre-slow-us21-co
  writeConnectionSecretToRef:
    name: k-sre-slow-us21-co-kyma-environment
    namespace: default
status:
  atProvider:
    brokerId: 1B1719DE-CC81-4686-A9E2-4631AA82D2BD
    createdDate: "1736321269760.000000"
    customLabels: {}
    description: created via crossplane-provider-btp-account
    environmentType: kyma
    globalAccountGUID: 2291c59f-008e-432d-a082-e3b49f9b5e26
    id: BC1ADB06-8997-4F95-A56D-7F731B143577
    modifiedDate: "1736321269760.000000"
    name: k-sre-slow-us21-co
    parameters: '{"administrators":["[email protected]"],"autoScalerMax":3,"autoScalerMin":3,"machineType":"Standard_D8s_v5","name":"k-sre-slow-us21-co","oidc":{"clientID":"","groupsClaim":"groups","issuerURL":"https://devexpdev.accounts.ondemand.com/","signingAlgs":["RS256"],"usernameClaim":"email","usernamePrefix":"-"},"orchestrate.cloud.sap/subaccount-operator":"ef2997b3-146e-453d-a109-7e65b86c7874","region":"eastus"}'

[sdischer-sap]

I just tried to reproduce that with exactly your data (apart from the users of course) and everything worked smoothly. So yes your data looks fine to me and I can't think of a reason why the provider should dismiss something from the API request there.

Do you have some other kyma environments to check against?
I noticed you are still using resources of the innersource provider, despite having the open source provider installed as well. Ideally try another one with the latest version of the open source provider to make sure there are no issues there.

[JayChanggithub]

@sdischer-sap
Thanks! Let me check the latest provider revision. However, I will delete the XRd resources, which means that deleting xkymaenvironments.sre.tools.sap k-sre-slow-us21-co-kn7t5 then trigger reconcile of GitOps should work without hardcoding the clientID.