Сборка Jenkins происходит на главном сервере, а не на подчиненном

Я работал над автоматизацией сборки ОС Android через Jenkins, репозиторий огромен, а сама сборка занимает довольно много времени. Следовательно, мне нужно запустить на моем ведомом устройстве, у которого гораздо больше мощности и потоков, доступных для сборки, и не заполнять дисковое пространство ведущего устройства до точки, когда другие разработчики не могут его использовать.

Когда моя первая сгенерированная сборка была развернута на главном сервере, я проверил конфигурацию и рассмотрел лучшие практики от Jenkins.

https: //wiki.jenkins. io / display / JENKINS / Jenkins + Best + Practices

Если у вас более сложная настройка безопасности, которая позволяет некоторым пользователям только настраивать задания, но не администрировать Jenkins, вам необходимо запретить им запускать сборки на главном узле, в противном случае у них есть неограниченный доступ к каталогу JENKINS_HOME. Вы можете сделать это, установив счетчик исполнителей на ноль . Вместо этого убедитесь, что все задания выполняются на ведомых устройствах. Это гарантирует, что мастер jenkins может масштабироваться для поддержки большего количества заданий, а также защищает сборки от случайного / злонамеренного изменения потенциально конфиденциальных данных в $ JENKINS_HOME. Если вам нужно выполнить некоторые задания на главном сервере (например, резервное копирование самого Jenkins), используйте плагин ограничений заданий, чтобы ограничить выполнение заданий на нем.

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

Master Server Executors

К моему удивлению, он все еще строится на мастере. Ниже мой файл Jenkins, в котором неявно говорится, что нужно использовать мой раб.

pipeline {
    agent {label 'van-droid'}

    stages {
        stage('Build') {
            steps {
        echo 'Building..'
        sh 'make clean'
        sh 'export USE_CCACHE=1'
        sh 'export CCACHE_DIR=/nvme/.ccache'
        sh './FFTools/make.sh'
             }
        }
    }
}

Кто-нибудь знает, что происходит?

2
задан 17 July 2018 в 22:10
3 ответа

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

1
ответ дан 3 December 2019 в 11:25

Также вы можете попробовать

agent {label '!master'}

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

1
ответ дан 3 December 2019 в 11:25

«К моему удивлению, он все еще основан на главном сервере».

ВСЕ сборки конвейера выполняются в мастере как «Легковесные» исполнители . Построение конвейера фактически начинается в тот момент, когда оно удаляется из очереди.

Both Actual executions on the master and Flyweight Executors

Обратите внимание на небольшую разницу в отображении.

В примере, показанном здесь, Мастер имеет 4 пронумерованных исполнителей, и два задания фактически выполняются на Мастере. Два других (выделены желтым для ясности) - это «Flyweights», также называемые OneOffExecutors, которые появляются на некоторое время, пока не будут отправлены в другое место, но они действительно работают на время выполнения задания. Вы можете увидеть, что выполняется на вашем главном компьютере как OneOff, используя такой запрос:

https: //YOUR.JENKINS.URL/computer/ (master) / api / python? Pretty = true & tree = oneOffExecutors [currentExecutable [fullDisplayName, result, id, url]] & depth = 1

Вам не обязательно использовать рендеринг на Python, но его легче читать, чем, скажем, XML.

Легковес или OneOffExecutors - это то, как мастер отслеживает и координирует работы на трубопроводе. Вы можете узнать о них больше по ссылке выше.

0
ответ дан 3 December 2019 в 11:25

Теги

Похожие вопросы