feat: include SPRING_CONFIG_IMPORT

[jessesimpson36]

Which problem does the PR fix?

related to #4878

The point of this change is to reduce how much users need to configure when they want to tweak one setting in application.yaml . in the related ticket, I shared an example that users can set an additional env var SPRING_CONFIG_IMPORT, but with this PR , a user would not need to know about that env var and wouldn't need to set it explicitly. they could just use the placeholder file additional-spring-properties and add extra options in there.

What's in this PR?

you can give this a try with

webModeler:
  restapi:
    extraConfiguration:
      additional-spring-properties.yaml: |
        logging:
          level:
            ROOT: DEBUG
            io.camunda.modeler: DEBUG
connectors:
  extraConfiguration:
    additional-spring-properties.yaml: |
      logging:
        level:
          ROOT: DEBUG
          io.camunda.connector: DEBUG
identity:
  extraConfiguration:
    additional-spring-properties.yaml: |
      logging:
        level:
          ROOT: DEBUG
          io.camunda.identity: DEBUG
orchestration:
  extraConfiguration:
    additional-spring-properties.yaml: |
      logging:
        level:
          root: DEBUG

Optimize is excluded from this PR since optimize does not use Springs default mechanism for importing configuration files.

Checklist

Please make sure to follow our Contributing Guide.

Before opening the PR:

• In the repo's root dir, run make go.update-golden-only.
• There is no other open pull request for the same update/change.
• Tests for charts are added (if needed).
• In-repo documentation are updated (if needed).

After opening the PR:

• Did you sign our CLA (Contributor License Agreement)? It will show once you open the PR.
• Did all checks/tests pass in the PR?

[hamza-m-masood]

@jessesimpson36 could you explain more about the value additional-spring-properties.yaml?
Does it append configuration to the existing application.yaml, or does it overwrite?
If the existing application.yaml is not modified and a new file is created, then isn't that the same as the existing behavior of extraConfiguration?

Also maybe it would be good to talk to PM about this? Since we are adding in java spring specific configuration into the values.yaml which would make it inconsistent, since not all apps are java based.

[jessesimpson36]

If the existing application.yaml is not modified and a new file is created, then isn't that the same as the existing behavior of extraConfiguration?

It is roughly the same as the functionality of extraConfiguration, in that customers need to currently use a snippet like this:

orchestration:
  env:
    - name: SPRING_CONFIG_IMPORT
      value: "optional:file:./config/additional-spring-properties.yaml"
  extraConfiguration:
    additional-spring-properties.yaml: |
      camunda:
        data:
          secondary-storage:
            type: rdbms
            rdbms:
              url: jdbc:postgresql://IP_ADDR:5432/camunda
              username: camunda
              password: YOUR_PASSWORD

But customers don't know about SPRING_CONFIG_IMPORT, so they often don't use extraConfiguration. The PR removes the need to set that env var explicitly .

could you explain more about the value additional-spring-properties.yaml?

Sure. it's not a special file. In fact, spring doesn't look at additional-spring-properties.yaml at all without the SPRING_CONFIG_IMPORT variable. Anything set in the file specified under SPRING_CONFIG_IMPORT will be treated as an overlay ontop of the other config file. so it would override anything in the normal application.yaml.

Also maybe it would be good to talk to PM about this?

they know about this PR. I sing it's praises every time I'm in a room with the PMs 😆