Как ограничить доступ к файлу настроек проекта всем на шаге mavenExecute конвейера cloud-s4-sdk?

Question

Мы работаем над реализацией конвейера s4sdk для доставки приложений SAP CloudFoun dry (пружинные микросервисы) с использованием SAP Cloud SDK для Java.

У нас работают несколько разработчиков несколько микро-сервисов, но все эти микро-сервисы имеют некоторые общие зависимости. Мы хотим контролировать версии для всех общих зависимостей из центрального местоположения. Для этого мы создали зависимость Maven BOM (ведомость материалов) и добавили ее в качестве родителя в pom. xml всех микросервисов. Вышеупомянутая спецификация размещена в репозитории Nexus, и все pom.xmls (из микро-сервисов) могут обращаться к родителю с помощью тега репозитория, как показано ниже.

   <repository> 
          <id>my-repo</id> 
          <name>nexus-repo</name> 
          <url>http://some/url</url> 
   </repository> `

Учетные данные для указанного выше репозитория Nexus помещаются в settings. xml file.

Мы хотим запустить вышеуказанную модель в конвейере cloud-s4-sdk. Хотя все работает нормально, проблема в том, что нам нужно предоставить учетные данные для доступа к репозиторию nexus в настройках. xml файл.

Согласно документации в https://github.com/SAP/cloud-s4-sdk-pipeline/blob/master/configuration.md#mavenexecute, настройки. xml для maven builds необходимо разместить относительно проекта root. Для нас это проблема безопасности, так как репозиторий проекта находится в GitHub и, как таковой, ProjectSettingsFile может быть доступен для разработчиков.

Мы не хотим, чтобы эти учетные данные были представлены разработчикам. Это должно быть ограничено только командой администраторов. Есть ли способ, которым мы можем достичь этого, используя конвейер cloud-s4-sdk?

Хотя nexus упрощает использование токена пользователя для параметров maven. xml, но здесь это не работает, поскольку GUI вход в систему по-прежнему возможен с использованием значений токена.

Answer 1

Я думаю, что вы могли бы рассмотреть следующие варианты:

Разрешить анонимный доступ для чтения артефактов Разработчикам в любом случае необходим способ создания артефактов локально. Как разработчики могут создать ваш сервис, не имея доступа к зависимости. Разрешение доступа на чтение также позволит им сделать это.

Передать учетные данные в git, но сделать git хранилище закрытым Если вы не хотите разрешить всем сотрудникам (я полагаю, только сотрудники имеют доступ к вашему нексусу), вы можете зафиксировать учетные данные вместе с настройками. xml, но сделайте хранилище приватным, чтобы не передавать эти данные.

Ввести учетные данные как переменную среды

Вы можете добавить учетные данные в качестве переменной среды в файл настроек xml. См. Также: Как передать параметры Maven с помощью переменных среды Настройка переменной среды, которую вы можете окружить полным конвейером в вашем Jenkinsfile с помощью шага withCredentials. Подробнее см. https://jenkins.io/doc/pipeline/steps/credentials-binding/

String pipelineVersion = "master"

node {
    deleteDir()
    sh "git clone --depth 1 https://github.com/SAP/cloud-s4-sdk-pipeline.git -b ${pipelineVersion} pipelines"
    withCredentials([usernamePassword(credentialsId: 'nexus', usernameVariable: 'NEXUS_USERNAME', passwordVariable: 'NEXUS_PASSWORD')]) {
        load './pipelines/s4sdk-pipeline.groovy'
    }
}

и настройки. xml, например:

    <username>${env.NEXUS_USERNAME}</username>
    <password>${env.NEXUS_PASSWORD}</password>