Eu tenho uma pergunta sobre a prioridade das variáveis de ambiente ao trabalhar comservidor de configuração da nuvem da primavera

No meu serviço, tenho um arquivo de propriedades localapplication.yml com este conteúdo

foo:
  bar: "some"
  buz: "some"
  joe: "some"

O serviço também está conectado a um servidor de configuração com um repositório de configuração que contém um arquivotestservice-api.yml (Ondetestservice-api é o nome do aplicativo de primavera do serviço). O conteúdo deste arquivo é:

foo:
  bar: "some-specific"

Portanto, com esta configuração, a configuração em tempo de execução resultaria no seguinte:

{
    "foo.bar": "some-specific",
    "foo.buz": "some",
    "foo.joe": "some"
}

Agora eu tento substituirfoo.bar efoo.joe com uma variável de ambiente.

Então, inicio o serviço com este comando:

FOO_BAR=some-env FOO_JOE=some-env gradle bootRun

Pelo que li emesta parte da documentação da bota primavera as variáveis de ambiente devem ter prioridade sobre os arquivos de configuração - também a documentação de configuração do Spring Cloud não indica sth diferente -, portanto, espero que o resultado seja:

{
    "foo.bar": "some-env",
    "foo.buz": "some",
    "foo.joe": "some-env"
}

Mas, em vez disso, recebo:

{
    "foo.bar": "some-specific",
    "foo.buz": "some",
    "foo.joe": "some-env"
}

Portanto, apenas a configuração do arquivo de configuração local dentro do jar é substituída pela variável de ambiente - a propriedade do repositório de configuração parece ter prioridade sobre a variável de ambiente.

Isso é explicável - ou isso é um bug? Alguma dica neste?

Encontre o código de exemplo aqui:

https://github.com/mduesterhoeft/configserver-test

O README no repositório lista o problema descrito aqui comoCaso de uso 3