Я работаю над автоматизацией сборки ОС 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, используя такой запрос:
Вам не обязательно использовать рендеринг на Python, но его легче читать, чем, скажем, XML.
Легковес или OneOffExecutors - это то, как мастер отслеживает и координирует задания конвейера. Вы можете узнать о них больше, перейдя по ссылке выше.