I had an initial pass over it, but I do not know all the details of what is going on. I might look again towards the end of the week... and btw, you have no tests here :)

I had an initial pass over it, but I do not know all the details of what is going on. I might look again towards the end of the week... and btw, you have no tests here :)

Thanks! I'll add the tests. For context, please check this issue.
tbh, This is my first open-source contribution, so I appreciate the feedback—I'll keep these points in mind.

It would be great to have some tests that actually test that the kubernetes environment repository works in a composite scenario.

It would be great to have some tests that actually test that the kubernetes environment repository works in a composite scenario.

Hey @ryanjbaxter,
Just to confirm, when we say "kubernetes environment repository works in a composite scenario," do we mean writing Composite Integration Tests where kubernetes is one of the type in the composite setup?

I am rethinking this a bit....

There are two ways to configure a composite environment repository

The first way you would do

spring:
  profiles:
    active: composite
  cloud:
    config:
      server:
        composite:
        - type: git
           uri: file:///path/to/rex/git/repo
        - type: kubernetes

But I don't think this would work with this PR because there is not kubernetes profile active.

The second way

spring:
 profiles:
   active: git, kubernetes
 cloud:
   config:
     server:
       git:
         uri: file:///path/to/git/repo
         order: 2

This should work fine I think

This should work fine I think

Sure, Will check this out

• As far as I know, the kubernetes profile is automatically included when the config server runs in a Kubernetes cluster, so there’s no need to explicitly define it in the spring.profiles.include / active property. This beahviour is due to this code
• The main advantage of using composite is the ability to define multiple instances of a profile.
• For example, my use case requires multiple Vault instances (application and infra) with different keys, along with Kubernetes and Git sources:

spring:
  profiles:
    active: composite
  cloud:
    config:
      server:
        composite:
          - type: kubernetes
          - type: vault
            defaultKey: application
          - type: vault
            defaultKey: infra
          - type: git
    kubernetes:
      secrets:
        enableApi: true

• Additionally, This configuration allows me to control the order of property sources.
• The above setup is working as expected in my environment and use case with code of this PR.

Do we have a specific reason to prefer the second approach over the composite model?

Sure, Will check this out

Please add a test for this

As far as I know, the kubernetes profile is automatically included when the config server runs in a Kubernetes cluster, so there’s no need to explicitly define it in the spring.profiles.include / active property. This beahviour is due to this code

I missed this in your tests but now I see it, sorry.

Do we have a specific reason to prefer the second approach over the composite model?

No but both are valid and wanted to make sure it is tested.

Hey @ryanjbaxter

While writing a test case for Scenario 2 of the composite configuration (comma-separated active profiles), I found that the composite environment repository sorts the repositories based on the order property. However, in the case of the Kubernetes environment repository, the ordering was not happening because we never defined an order property for it.

Taking reference of similar profile types in Spring Cloud Config Server (e.g., Vault, Native, Git ), I found that there, we pass the order property via properties when creating their environment repository beans. However, the Kubernetes environment repository bean was missing this argument.

I initially considered accepting order as an environment variable and injecting it using @Value, but this felt like a workaround.
For a consistent approach and proper ordering, I have:

1. Introduced an KubernetesConfigServerProperties argument in the Kubernetes environment repository bean (following the pattern used by other profiles).
2. Added relevant test cases to verify the expected ordering behaviour.

Let me know if you have any concerns or if you'd like to discuss alternative approaches!