Команда установки Maven с файлом переменных среды - PullRequest
0 голосов
/ 20 апреля 2020

Есть ли способ выполнить файл переменных среды .env вместе с такими командами maven, как mvn clean install или mvn clean deploy. Основная идея концепции заключается в том, что я ищу аналогичное решение:

mvn clean install -DenvFile=/path/<filename>.env

ИЛИ

mvn clean deploy -DenvFile=/path/<filename>.env

ИЛИ

mvn clean package -DenvFile=/path/<filename>.env

Примечание: Не пытается создать среду, определяющую c сборок. В среде dev мое намерение запустить тесты junit со всеми переменными среды, настроенными с <filename>.env.

, где приведенные выше команды maven должны установить все переменные окружения с <filename>.env и затем выполнить плагины maven. В IntelliJ есть плагин envFile, который точно так же делает.

Не хочу, чтобы в моем проекте были указаны параметры среды c properties dev|staging|prod.properties, потому что он грязный и сложный в управлении. Я бы предпочел иметь один единственный спецификатор среды c файл filename.env, который содержит все динамические / изменяемые свойства.

application.properties

spring:
  cloud:
    config:
      uri: http://config-service:${CONFIG_SERVICE_PORT}
      fail-fast: true
      password: ${CONFIG_SERVICE_PASSWORD}
      username: user

Файл среды: .env

CONFIG_SERVICE_PORT=8080
CONFIG_SERVICE_PASSWORD=123

Теперь, когда я развертываю приложение в разных средах, таких как AWS, GCP и Azure. Все, что мне нужно, чтобы изменить переменные среды в файле .env и запустить приложение java -DenvFile=/path/<fileName>.env -jar application.jar, и оно сделает magi c.

Моя проблема связана с плагином maven-sure-fire для тестирования в dev-mode, которые требуют этих переменных окружения для spring context.

Буду признателен за любую помощь.

1 Ответ

1 голос
/ 20 апреля 2020

Хорошо, из ваших комментариев кажется, что вы ищете два разных решения:

  1. Запустите приложение в разных средах с помощью java -DenvFile=/path/<fileName>.env -jar application.jar
  2. Решения для запуска тестов.

Это разные проблемы, которые я попытаюсь решить как

Проблема 1

Когда вы запускаете java -jar, это означает, что Артефакт уже собран (с помощью весеннего загрузочного плагина maven, насколько я понимаю). Этот jar - готовое к go приложение для весенней загрузки, и maven здесь в основном не имеет значения - maven - это система сборки, spring - среда выполнения, и мы говорим о среде выполнения.

Spring boot имеет много способов достичь того, что вы хотите. "Родной" способ весенней загрузки, близкий к вашей ситуации, - это запуск приложения с "--spring.config.location = file: // со всеми необходимыми конфигурациями

Это выглядит так (см. здесь для полной документации):

java -jar application.jar --spring.config.location=myprops.properties

Даже если у вас есть некоторые свойства, определенные в src/main/resources/application.properties, этот метод позволяет эффективно их переопределять, предоставляя способ запускать различные конфигурации в разных средах.

Это имеет преимущество перед файлами .env, потому что он может работать одинаково во всех ОС, даже Windows;) Поскольку Java не зависит от ОС - я считаю, что это лучшее, чего вы можете достичь .

Конечно, вы можете обернуть строку java -jar в какой-то сценарий bash и загрузить / выполнить серию команд export перед запуском jvm, но, опять же, это менее "spring-y". "way.

Issue 2

Maven запускает тесты (модуль / интеграция) таким образом, что плагин maven с пружинной загрузкой не имеет значения. Все о надежном / отказоустойчивом Sprin g framework для тестирования загрузки.

Я предполагаю, что вы спрашиваете об интеграционных тестах, потому что я считаю, что все это не имеет значения для модульных тестов, поскольку они вообще не должны требовать каких-либо переменных среды и должны выполняться без пружины при все (junit / mockito должен делать эту работу)

Я также позволю себе предположить, что способ переопределения / настройки приложения весенней загрузки через файл yaml или свойств лучше, чем .env и обеспечит Решение для конфигурации весенних тестов здесь:

С этими допущениями вы можете создать файл yaml по следующему пути: src/test/resources/application-test.yml

Этот файл может содержать конфигурации, относящиеся к тестам, и переопределит все, что написано в src/main/resources/application.yml. Обратите внимание, поскольку application-test.yml находится в исходных текстах тестов, плагин Spring Boot Maven не будет упаковывать его в приложение.

В зависимости от точного способа выполнения интеграционных тестов вы можете также использовать аннотацию @TestPropertySource для предоставления файл пользовательских свойств / yaml, который не соответствует стандартным правилам весенней загрузки. Это особенно полезно для тестов с пружинным приводом, которые не поддерживают bootstrap с полной поддержкой пружинной загрузки (прочитайте тесты, в которых используется пружинный бегун Junit, но нет аннотации @SpringBootTest)

Другая, возможно, полезная аннотация @ActiveProfile("myprofile"). Это приведет к тому, что весенние загрузочные тесты автоматически загрузят файл src/test/resources/application-myprofile.yml (или application-myprofile.properties)

И последнее, но не менее важное: второй комментарий будет ссылаться на «dev / prod / staging / properties» в источнике. Когда дело доходит до тестов - должен быть только один файл application-test.yml. Однако обратите внимание, что когда вы используете yaml, можно определить конфигурации для многих профилей весенней загрузки в одном файле:

# default value
foo:
 bar: 1

---
spring:
  profiles: staging
foo:
  bar: 2

--- 
spring:
  profiles: prod
foo:
  bar: 3

Некоторые соответствующие SO thread

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...