Назад | Перейти на главную страницу

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

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

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

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

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

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

К моему удивлению, он все еще опирается на мастера. Ниже мой файл 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'
             }
        }
    }
}

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

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

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

agent {label '!master'}

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

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

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

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

В показанном здесь примере у мастера есть 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 - это то, как мастер отслеживает и координирует задания конвейера. Вы можете узнать о них больше, перейдя по ссылке выше.