Одиночная работа Дженкинса для всех репозиториев в организации Github

Question

У нас есть организация Github с сотнями репозиториев, созданными участниками. Мы хотели бы настроить сервер Jenkins, который выполняет определенные стандартные задачи для каждого коммита в любом репозитории в нашей организации Github. Предполагаемый поток CI довольно прост:

1. Пользователь совершает изменение в репо myorg/foobar
2. Веб-узел Github для myorg звонит на сервер Jenkins
3. Дженкинс запускает команду docker для выполнения задач для myorg/foobar
4. Jenkins устанавливает статус фиксации в в ожидании , включая ссылку на вывод хода выполнения команды
5. По завершении Дженкинс обновляет статус окончательной фиксации до успех или сбой

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

Я пытался создать Jenkins "GitHub Organization" для моей организации Github, но она просто сообщает мне "Эта папка пуста, не найдено ни одного репозитория, содержащего сборочные проекты" . Мне также неясно, где должен быть настроен webhook организации github.

Мы не хотим настраивать отдельные рабочие места / jenkinsfiles / webhook для всех репозиториев, а просто используем стандартный скрипт, который запускается для любого коммита в каждом репо, и запускаем его через один веб-крючок организации gh. Это возможно?

Answer 1

Отвечая на мой собственный вопрос:

Как указали несколько человек, Дженкинс выполняет одну работу на хранилище.Плагин Github Organization не работал должным образом, потому что он неуклюж и требует от вас фиксации и поддержки Jenkinsfile для каждого из ваших репозиториев, чего я и хотел избежать.

Критическая часть информации, которуюЯ не знаю, что у Jenkins есть превосходный API-интерфейс CLI и REST для управления заданиями, а конфигурацию одного задания можно легко экспортировать в виде простого XML-файла.

Итак, я настроил задание Jenkins для одного из репозиториев через графический интерфейс Jenkins.Затем я написал простой REST-клиент, который загружает config.xml для этих заданий и создает или обновляет задания Jenkins для каждого из репозиториев в нашей организации Github.

Сборки автоматически запускаются веб-крючком Github (для всей организации), если URL-адрес совпадает с URL-адресом любого из репозиториев.Никакого специального плагина Github Organization не требуется.

Answer 2

Стандартный подход заключается в создании нового многоотраслевого конвейера, который сканирует вашу организацию на наличие новых репозиториев.Каждый репозиторий должен иметь jenkinsfile с инструкциями по сборке.Но в целом также возможно добиться того, что вы пытаетесь программным способом.

Какой мой подход будет:

1. Создание шаблона работы в виде config.xml (сценарий оболочкизапустить docker для проверки определенных вещей)
2. Сканирование GitHub для поиска новых репозиториев
3. Создание нового задания jenkins на основе temnplate (в идеале просто замените ссылку SCM на новое местоположение) Как создать задание с использованием REST-API-and-cURL
4. Запустить это задание

Я бы использовал папки Плагин для создания папки для этого типа заданий.

Если это то, что вы действительно пытаетесь сделать, я мог бы уточнить.

Answer 3

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

Я разрабатываю процедуру, которой нужно следовать, используя конвейеры Jenkins , если не сейчас, то в какой-то момент вам нужно переместить свою сборку и развернуть ее в конвейеры для инфраструктуры в виде кода .

Начиная с плагинов Jenkins , следующие обязательные плагины для процедуры, которую я буду объяснять здесь:

• Организация Github - для сканирования организации с несколькими репо
• Многоотраслевой конвейер - для автоматического создания конвейеров для всех филиалов / PR в репо.Это помогает проверять ветви функций и изменения PR.

Конфигурация Jenkins

1. Создать Github organization из следующих параметров:

Настройте вновь созданную организацию, начиная с шага выше.Owner должен быть вашим Organization, где доступны сотни репозиториев.

также, настройте какой файл и чтоветви , чтобы заглянуть в репо, чтобы запустить сборку.script path - это файл, который выполняет шаги (возможно, создает и развертывает) для репозиториев.Таким образом, все репо будут обнаружены или показаны в Jenkins, только если файл с этим именем доступен в репозиториях.

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

Git-репо / конфигурация организации

Настройка веб-хуков в github

Настройка событий, которые требовать уведомления Дженкинса .

Защита филиала и проверки состояния для PR

Защита ветви путем включения надлежащих проверок поможет ограничить коммиты от нескольких групп людей после того, как проверки статуса пройдены .Это помогает поддерживать хорошее качество кода.

Вот снимок, который показываетстатус проверяет статус при повышении PR .На основании этого рецензенты смогут принять решение об утверждении ОР.

Эта ссылка подробно объясняет процедуру, которую я описал здесь.

https://github.com/gitbucket/gitbucket/wiki/Setup-Jenkins-Multibranch-Pipeline-and-Organization

Answer 4

Предполагая, что ваш Jenkins работает в Linux или MacOS или в Windows, поддерживающей команды Shell Script, настройте задание Jenkins для выполнения приведенного ниже сценария. Не забудьте заменить поля пользователя и пароля и прочитать строки комментариев, чтобы понять и, возможно, улучшить их.

curl -i -u "user":"password" "https://github.com/your_organization" | grep "codeRepository" | awk -F '"' '{print $8}' | while read line; do
    mkdir "_temp_repo"
    cd "_temp_repo"

    # `--depth=1` clones the last commit only improving the speed of the clone
    # if you want to clone a specific branch add `-b branch` to the command below
    git clone --depth=1 "https://github.com"$line .

    # execute here your peding commands...

    git add .
    git commit -am "[pending] XPTO..."

    git push

    # execute here your success/failure commands...

    git add .
    git commit -am "[success/failure] XPTO..."

    git push

    cd ..
    rm -rfv "_temp_repo"
done

Я бы предложил создать файл SH и выполнить его в подробном режиме: sh -x ./my_script.sh.

Чтобы выполнить это для каждого нового обновления, настройте Github webhook на это задание.

Answer 5

У вас есть более одного требования здесь. Давайте пройдемся по одному.

a) Jenkins GitHub Organization: это отсканирует всю вашу организацию GitHub и создаст столько заданий, сколько необходимо для создания ваших репозиториев, поскольку наличие только одного задания в Jenkins не является стандартом. По сути, вы потеряли исторические данные (Дженкинс понятия не имеет, что строит разные вещи на каждой итерации). В справке говорится: «Проверяет организацию GitHub (или учетную запись пользователя) на наличие всех репозиториев, соответствующих определенным маркерам».

б) Попытайтесь рассматривать Дженкинса как автоматора, а не то, что будет содержать всю логику сборки / развертывания. Что я делаю, так это создаю файлы типа "build.sh", "deploy.sh" и так далее. Таким образом, я могу создавать и развертывать прямо из моей оболочки. Поэтому только после этого я создаю сценарии для Jenkins, которые просто вызывают сценарии сборки / развертывания, независимо от того, что они на самом деле делают. Дженкинс не должен знать. Побочным эффектом является то, что все ваши проекты «могут быть построены одинаково», независимо от того, являются ли они NodeJS, Python или чем-то еще. Конечно, в некоторых случаях вам могут понадобиться дополнительные зависимости, и Docker действительно может помочь здесь.

в) В прошлом я делал нечто подобное, имея меньше заданий, чем репозитории / филиалы / pull-запросы. Дженкинс - своего рода дамп, и здесь могут помочь несколько плагинов. Но в вашем случае, если вы действительно хотите иметь одну работу, вам нужна только обычная параметризованная работа. Хитрость в том, что глобальный веб-крюк вашей организации Github не будет указывать на Дженкинса. Он должен указывать куда-то еще, какой-то код, который вы поддерживаете. Этот код может анализировать полезную нагрузку Github, анализировать его, может в конечном итоге перезвонить GitHub («есть ли запрос на извлечение для этой ветви? Нет? Затем забудьте об этом»), чтобы улучшить его дерево решений и, в конце, инициировать это единственное задание на Дженкинс со всеми параметрами, которые вы смогли зафиксировать. Такие параметры будут указывать единственное задание, на какое репозиторий клонировать, env для развертывания и все. Вы уже знаете имена скриптов, так как они являются стандартными.

d) Тем не менее, я бы спросил ... тебе нужен Дженкинс? Может ли это маленькое программное обеспечение синтаксического анализатора на самом деле клонировать ваш репозиторий и запустить несколько скриптов в контейнере Docker? Контейнер-строитель-докер, внутри которого есть все зависимости?

e) По поводу "разговора" с GitHub, я сделал это с помощью Python. Существуют библиотеки GitHub, поэтому я смог получить информацию от Дженкинса и делать посты API, чтобы кормить GitHub статусами сборки. Так как я фактически использовал экземпляр Jenkins, моим инструментом был посредник посредник. В вашем случае, для одной работы, контейнер Docker будет хорошо играть роль.

Надеется, что это поможет с другой точки зрения.

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