Как настроить Jenkins для @Grab зависимостей из Artifactory в изолированном скрипте конвейера - PullRequest
Новая
       24

Как настроить Jenkins для @Grab зависимостей из Artifactory в изолированном скрипте конвейера

1 голос
/ 07 ноября 2019

Я могу использовать аннотацию @Grab в конвейерном скрипте Jenkins как в песочнице, так и в песочнице. Моя проблема в том, что по умолчанию разрешения разрешаются в центральном репозитории maven, но мне нужно разрешить их в отношении нашей компании Artifactory. Чтобы продемонстрировать проблему, вот простой конвейерный скрипт: 

//@Grab(group = 'my.compay', module='my-module-name', version='1.0.0-SNAPSHOT')
//import my.company.MyFancyClass
@Grab('com.google.guava:guava:23.0')
import com.google.common.base.Joiner

pipeline {
    agent any
    stages {
        stage('Grape Test') {
            steps {
                echo "Joiner: ${Joiner.class}"
                // echo "MyFancyClass: ${MyFancyClass.class}"
            }
        }
    }
}

Когда я запусту скрипт как есть, я увижу в выводе полное имя класса. Однако, когда я раскомментирую закомментированные строки, которые работают с зависимостями, выставленными в сценарии артефакта компании, происходит сбой со следующим: 

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 2: unable to resolve class my.company.MyFancyClass
 @ line 1, column 1.
   @Grab(group = 'my.company', module='my-module-name', version='1.0.0-SNAPSHOT')

1 error

После исследования я обнаруживаю, что @Grab использует специфическую для Groovy вещь, называемую Grape, которая описана здесь . Упомянутая документация описывает, как настроить Grape для использования ваших собственных репозиториев с использованием настроек ivy в файле ~ / .groovy / grapeConfig.xml. Я нашел решение и заставил его работать для обычного кода Groovy со следующим содержимым: 

<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<credentials host="localhost" realm="Artifactory Realm" username="USERNAME" passwd="PASSWORD"/>
<resolvers>
  <chain name="downloadGrapes" returnFirst="true">
    <filesystem name="cachedGrapes">
      <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
      <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"/>
    </filesystem>
    <ibiblio name="localm2" root="file:${user.home}/.m2/repository/" checkmodified="true" changingPattern=".*" changingMatcher="regexp" m2compatible="true"/>

    <ibiblio name="maven-release" m2compatible="true" root="http://artifactory:8081/artifactory/maven-release"/>
    <ibiblio name="maven-snapshot" m2compatible="true" root="http://artifactory:8081/artifactory/maven-snapshot"/>
    <!-- todo add 'endorsed groovy extensions' resolver here -->
    <ibiblio name="jcenter" root="https://jcenter.bintray.com/" m2compatible="true"/>
    <ibiblio name="ibiblio" m2compatible="true"/>
  </chain>
</resolvers>
</ivysettings>

К сожалению, этот конфигурационный файл ivy исправляет мою проблему только частично, и заставляет Grapes работать должным образом только из обычного кода Groovy (то же самое для вызовакоманда grape из CLI).

Я понятия не имею, как Jenkins использует Groovy / Grapes, но он явно игнорирует расположение по умолчанию для этого файла. Я прочитал несколько документов Ivy и обнаружил, что можно настроить некоторые параметры Ivy, например, расположение файла конфигурации, используя свойства. Вот почему я попытался убедить Дженкинса эффективно использовать мой конфиг, запустив его из CLI с помощью следующей команды: 

java -Divy.settings.file=%USERPROFILE%\.groovy\grapeConfig.xml -jar jenkins.war --httpPort=8888

Это действительно работает, но, к моему удивлению, снова лишь частично! Это работает только когда я отключаю режим песочницы для моего конвейерного скрипта. Если я включу его, я снова смогу захватывать зависимости только из maven central.

Любые идеи приветствуются ...

...