Должен ли я использовать пользователя сборки или пользователя jenkins для создания проектов? ie кто должен владеть артефактами сборки в jenkins?

Question

Что является стандартным для построения больших проектов в jenkins (например, 80Gig зависимых заданий, создающих библиотеки и бинарные файлы из одного репо)?
, если вы разбиваете эту большую сборку на задания, которые строят библиотеки и другие которые собирают нисходящие приложения, следует ли вам использовать пользователя jenkins для сборки проекта или настроить отдельного пользователя сборки для сборки проекта?

Что если вы переключитесь на удаленный агент с помощью S SH?
пользователю jenkins запрещено по умолчанию удаленно подключаться к другому хосту из-за этого /bin/false здесь:

$ grep jenkins /etc/passwd
   jenkins:x:996:992:Jenkins Automation Server:/var/lib/jenkins:/bin/false

, значит ли это, что все задания фермы выполняются как пользователь сборки или вам изменить этот параметр на /bin/sh, чтобы завершить сеанс s sh как пользователь jenkins? Или используйте только агенты setup JNLP ?

Если вы строите библиотеки на мастере jenkins, должен ли .o и двоичные файлы принадлежать jenkins или нет?
Если вы используете специализированный мастер jenkins, должны ли исполнители быть агентами, настроенными на использование пользователя сборки, а не пользователя jenkins?

Если вы используете монтирование типа NFS для совместного использования артефактов сборки, как это выглядит?
Относится к 2 предыдущим вопросам - все локальные задания будут принадлежать владельцу сборки под пользователем jenkins. Значит ли это, что вы используете пользователя сборки и используете удаленный узел для localhost в качестве пользователя сборки только для того, чтобы все артефакты имели одного и того же пользователя для использования всеми локальными и удаленными агентами?

Это может звучать глупо, но Я не могу найти каких-либо указаний о том, кто должен быть владельцем сборки или каков наилучший способ создания очень большой одиночной git сборки проекта репо разумным способом (владельцы репо не хотят разбивать код на разные репо из-за ссылки c) .

Answer 1

По нашему опыту (очень большой монорэпо, 250+ рабов):

1. Мы объединили несколько рабочих мест в одну большую работу, с параллельными этапами, где это применимо, чтобы можно было создавать независимые вещи в одновременно на разных рабах (чтобы сократить время). Таким образом, легче следить за тем, что не удалось и почему, и у вас есть все артефакты в одном месте, и есть один Jenkinsfile для отслеживания.

2. Все наши рабы настроены как JLNP, и когда они перезагружаются, они запускают jenkins-agent. На наших рабах нет пользователя jenkins.

3. Поскольку вы должны собрать все артефакты и в конце их заархивировать, желательно очистить ведомое устройство в нулевое состояние, это не имеет значения кто владеет этим, и вы всегда можете изменить его с помощью chown.

4. NFS не будет отличной идеей для нас, так как это будет серьезно ограничено сетью и диском Применение. Мы используем Docker реестр для docker изображений, но Artifactory может работать, если вы не используете Docker. minio будет другим вариантом.