Введение
Cedar & Common планирует праздник района. Официальная программа уже доступна, а двум предлагаемым планам нужны отдельные предварительные версии. Jenkins может собрать обе ветки, но их текущие Pipeline публикуют результат в одном месте. Одной успешной сборки недостаточно, чтобы оба варианта оставались доступными.
Вы обнаружите ветки, понаблюдаете за этим конфликтом, измените их Jenkinsfile и опубликуете две пригодные для использования предварительные версии. Затем вы измените время одной встречи и убедитесь, что её предварительная версия обновилась, а другой план остался нетронутым.
Необходимы базовые навыки ввода команд в терминале и работы с путями, навигации по страницам Jenkins и умение распознать короткий Declarative Pipeline. Ветки Git, коммиты, отправка изменений, индексирование и новые настройки Pipeline объясняются до использования. Репозиторий, средство сборки на Java, средство публикации и плагины Jenkins подготовлены; устанавливать их или писать сайт не нужно. Это локальный учебный источник кода и сервис предварительных версий на одной виртуальной машине, а не GitHub или промышленная платформа развёртывания. Продолжительность — авторская оценка, а не измеренное время для начинающих.
Изучите планы и обнаружьте сборки их веток
На этом шаге вы изучите обычные программы и исходный код кандидатов, затем обнаружите задания их веток и понаблюдаете за конфликтом общей предварительной версии. Начните в Preview Desk.
Выберите Open the official program. Подтвердите Common Ground Day и 09:30. Выберите Explore this plan и проверьте три мероприятия и иллюстрацию маршрута. Выберите Download the activities, чтобы получить настоящий CSV, и Read visitor notes, чтобы прочитать полный текст. Действием браузера Back вернитесь к обзору, затем ещё раз Back — к Preview Desk. Также откройте Read the courtyard notes и подтвердите Courtyard Stories. Обе существующие программы должны оставаться доступными на протяжении всей работы.
Переключитесь в Source. Этот терминал содержит рабочую копию Git: файлы, которые вы можете редактировать, в каждый момент относятся к одной выбранной ветке. Ветка — именованная линия истории исходного кода. Переключение веток меняет рабочие файлы на версию выбранной ветки; другую ветку оно не меняет. Коммит — записанная версия содержимого репозитория, определяемая хешем; этот идентификатор свяжет сборку Jenkins с её исходным кодом.
Терминал открывается в /home/labex/project/community-site. pwd выводит текущий каталог. git --no-pager branch --list выводит локальные ветки, отмечая выбранную символом *. --no-pager оставляет результат прямо в терминале. Без этой опции Git может открыть интерактивную программу просмотра; если вместо приглашения оболочки вы видите (END), нажмите q, чтобы выйти из просмотра. Выполните:
pwd
git --no-pager branch --list
В списке есть main, courtyard-notes, garden-plan и river-plan. Подготовленная выбранная ветка — garden-plan. Если вы случайно сменили каталог, перед продолжением вернитесь командой cd /home/labex/project/community-site.
cat выводит файл, не изменяя его. event.properties хранит по одной настройке key=value в строке для названия, сведений о встрече и мероприятий. Прочитайте этот небольшой файл данных:
cat event.properties
Он описывает Garden Gathering со встречей в 10:00 у Glasshouse gate. Строка meeting_time — данные для предоставленного средства сборки, которое совместно создаёт страницы, CSV и памятку.
git switch выбирает ветку в этой рабочей копии. Сравните второго кандидата, затем вернитесь:
git switch river-plan
cat event.properties
git switch garden-plan
Второй план — Riverside Picnic, встреча в 14:00 у River steps. Это действительно разные исходные файлы, а не одна страница с другой меткой ветки.
Разрешено редактировать Jenkinsfile веток-кандидатов и позднее внести запрошенное изменение meeting_time в event.properties. Оставьте шаблоны, изображение маршрута, средство сборки и средство публикации без изменений. Не редактируйте, не удаляйте, не переименовывайте и не создавайте заново подготовленный проект Jenkins или задания веток. Сохраните всю историю Git и Jenkins и все сохранённые архивы предварительных версий, ветки main и courtyard-notes, официальную программу и предварительную версию двора. Docker и команды администратора в этом упражнении не нужны.
На этом этапе определите, какой кандидат начинается в 10:00, а какой — в 14:00. Пока ни одна предварительная версия кандидата не опубликована.
Теперь выполните встроенное обнаружение веток Jenkins и сравните успешные сборки с фактическим результатом их публикации. Переключитесь в Jenkins и откройте community-previews из Dashboard.
Этот подготовленный родительский проект — Multibranch Pipeline. Он сканирует репозиторий Git в поисках веток с Jenkinsfile и создаёт дочернее задание Pipeline для каждой из них. Источник использует небольшой сервис Git только для чтения внутри учебной среды; подготовленный origin рабочей копии — место, куда вы позднее отправите изменения исходного кода. Внешняя учётная запись и учётные данные не нужны.
Дождитесь полной загрузки страницы Jenkins, затем выберите Scan Multibranch Pipeline Now. Откройте Scan Multibranch Pipeline Log и дождитесь Finished: SUCCESS. Сканирование обнаруживает garden-plan и river-plan; main и courtyard-notes не содержат Jenkinsfile и не становятся заданиями кандидатов. Вернитесь через community-previews в навигационной цепочке. Дождитесь завершения обеих дочерних сборок.
Откройте garden-plan, затем сборку с её номером и Console Output. Вывод должен указывать Garden Gathering, 10:00 и полученную ревизию исходного кода. Вернитесь через community-previews, откройте river-plan и изучите консольный вывод сборки с её номером. Он должен указывать Riverside Picnic, 14:00 и собственную ревизию исходного кода. Обе должны завершиться с SUCCESS. В этой подготовленной среде перед успешным получением исходного кода может появиться сообщение инструмента Git Using Default; о завершении получения судите по фактической ревизии и окончательному результату.
Переключитесь в Source. Прочитайте предоставленный Pipeline:
cat Jenkinsfile
options { skipDefaultCheckout() } отключает неявное получение исходного кода Declarative Pipeline, чтобы видимый этап Check out this branch выполнял его явно. checkout scm использует конкретную ревизию ветки, из которой получен этот Jenkinsfile. Не заменяйте его получением фиксированной ветки.
Предоставленный этап Build preview превращает полученный исходный код в настоящие файлы для посетителей. Archive preview сохраняет preview.zip в Jenkins, прежде чем Publish preview отправляет те же байты в локальный Preview Desk. Заключительный блок post использует deleteDir() для очистки рабочего каталога этой сборки. Сохраните эти этапы и очистку.
Блок environment предоставляет значения этапам. Сейчас обе ветки содержат одинаковую настройку:
PREVIEW_KEY = 'shared'
PREVIEW_KEY выбирает адрес публикации в Preview Desk. Строковый литерал 'shared' отправляет обе сборки в одно место, хотя их исходный код получен из разных веток. Вернитесь в Preview Desk и обновите страницу. Здесь одна карточка кандидата shared, показывающая ветку, которая опубликовалась последней. Выберите её ссылку Open preview и сравните название с двумя успешными исходными сборками. По одному этому адресу нельзя предоставить две независимые предварительные версии.
Действием браузера Back вернитесь к Preview Desk. Официальная программа и памятка двора должны по-прежнему работать. Теперь вы увидели, почему отдельные задания веток не означают автоматически отдельных опубликованных результатов.
Дайте каждой ветке свою предварительную версию
На этом шаге вы измените и опубликуете Jenkinsfile каждой ветки, затем соберёте обе независимые предварительные версии. Начните в Source, в /home/labex/project/community-site.
Jenkins предоставляет env.BRANCH_NAME в сборке Multibranch. Это имя текущей ветки, например garden-plan. Замените общее значение этим встроенным идентификатором ветки:
PREVIEW_KEY = "${env.BRANCH_NAME}"
Двойные кавычки Groovy позволяют ${...} подставить значение переменной. Одинарные кавычки вокруг этого выражения сохранили бы его буквальные символы. Имена веток в этом упражнении уже состоят из простых строчных букв и дефисов, пригодных для адресов предварительных версий; это не общее правило очистки произвольных имён веток.
Сначала выберите кандидата сада. git status --short кратко показывает незакоммиченные изменения; M означает изменённый файл, а отсутствие вывода — чистую рабочую копию. nano — терминальный редактор указанного файла; он управляет этим терминалом до сохранения и выхода.
git switch garden-plan
git status --short
nano Jenkinsfile
nano редактирует указанный файл в этом терминале. Стрелками перейдите к строке PREVIEW_KEY. Нажмите Home, чтобы перейти к её началу, затем один раз Ctrl+K, чтобы вырезать эту одну строку. Введите полную строку замены, показанную выше, включая отступ, и нажмите Enter, чтобы следующая строка RECEIVER_URL оставалась отдельной. Не вырезайте дополнительные строки. Сохраните через Ctrl+O, нажмите Enter для подтверждения Jenkinsfile, затем выйдите через Ctrl+X. Здесь Ctrl означает удерживание клавиши Control, в том числе в macOS.
Проверьте изменение перед записью в историю Git. git diff сравнивает рабочий файл с его закоммиченной версией. Как и ранее, --no-pager выводит прямо в терминал; -- отделяет опции от пути файла. Выполните:
git --no-pager diff -- Jenkinsfile
Различия должны показывать только удалённую старую строку PREVIEW_KEY и добавленную новую. Префиксы - и + обозначают удалённый и добавленный текст; вводить эти символы в файл не нужно. Если различия включают нежелательное изменение, снова откройте nano Jenkinsfile, исправьте его, сохраните, выйдите и проверьте ещё раз. Если появилась ошибка отсутствующего файла, выполните pwd и вернитесь в указанный выше рабочий каталог.
Коммит записывает подготовленное изменение исходного кода в выбранной ветке. git add подготавливает этот файл к коммиту; git commit -m записывает его с предоставленным сообщением; git push origin garden-plan публикует ветку в подготовленном репозитории origin, чтобы Jenkins смог обнаружить новый коммит. В этих командах коммита двойные кавычки объединяют сообщение из нескольких слов в один аргумент. Команды меняют историю исходного кода, а не предварительную версию напрямую:
git add Jenkinsfile
git commit -m "Give the garden plan its own preview"
git push origin garden-plan
Теперь примените ту же настройку к другому кандидату:
git switch river-plan
git status --short
nano Jenkinsfile
Замените только его строку PREVIEW_KEY тем же действием в nano и точным выражением в двойных кавычках. Сохраните и выйдите. Проверьте, создайте коммит и отправьте эту ветку:
git --no-pager diff -- Jenkinsfile
git add Jenkinsfile
git commit -m "Give the river plan its own preview"
git push origin river-plan
Если Git отказывается переключаться из-за незакоммиченных изменений, сначала выполните git status --short и изучите различия в текущей ветке. Завершите или исправьте запланированное изменение перед переключением; не отбрасывайте файлы и не сбрасывайте репозиторий. Если git commit сообщает, что коммитить нечего, после того как вы уже закоммитили нужное изменение, изучите git --no-pager log -1 --oneline и продолжите отправкой ветки. -1 ограничивает просмотр одним коммитом; --oneline показывает его короткий идентификатор и сообщение.
Переключитесь в Jenkins, вернитесь в community-previews через навигационную цепочку и снова выберите Scan Multibranch Pipeline Now. В этом локальном упражнении нет вебхука, поэтому одна отправка исходного кода не запрашивает сканирование. Дождитесь успешного завершения сканирования и обеих новых дочерних сборок. Каждая консоль должна показывать ключ предварительной версии своей ветки. Если сборка сообщает о синтаксической ошибке Groovy, исправьте кавычки и фигурные скобки её Jenkinsfile в Source, создайте и отправьте коммит исправления в этой ветке, затем снова выполните сканирование. Не редактируйте созданное дочернее задание вместо его исходного кода.
Переключитесь в Preview Desk и обновите страницу. Теперь должны быть отдельные карточки garden-plan и river-plan. Старая общая карточка может остаться как наблюдавшийся предыдущий результат. Откройте ссылку Open preview каждого кандидата и проверьте правильные название, время встречи, три мероприятия, изображение маршрута, CSV и памятку для посетителей. После изучения плана действием браузера Back вернитесь к его обзору, затем ещё раз Back — к Preview Desk, прежде чем открывать другую карточку. Адреса двух предварительных версий должны различаться и оставаться пригодными для использования одновременно.
Найдите ключи garden-plan и river-plan над их собственными названиями и исходным временем встречи. Сохранённая карточка shared показывает предыдущий конфликт; она не заменяет ни одну из независимых предварительных версий.
В Jenkins откройте страницу статуса последней успешной сборки каждой ветки и скачайте preview.zip из Build Artifacts. Распакуйте каждый ZIP в отдельную новую папку и откройте index.html. Держите все семь файлов вместе. Страницы и вложения должны работать локально; текстовое вложение может открыться напрямую вместо повторного скачивания. build.json указывает фактическую исходную ветку и коммит. Результат — эти полные предварительные версии; двух зелёных меток сборки недостаточно.
Обновите один план и сохраните другой
На этом шаге вы измените время встречи в саду и новым сканированием обновите предварительную версию только этой ветки. Начните в Jenkins и запишите номер последней успешной сборки river-plan. Оставьте её предварительную версию открытой для сравнения.
Переключитесь в Source. Выберите ветку сада и отредактируйте её небольшой файл данных:
git switch garden-plan
git status --short
nano event.properties
Измените только полную строку meeting_time со значения meeting_time=10:00 на:
meeting_time=10:30
Используйте ту же последовательность со стрелками, Home, одним нажатием Ctrl+K, текстом замены и Enter, что и для строки Pipeline. Сохраните через Ctrl+O, Enter и выйдите через Ctrl+X. Средство сборки читает это одно значение, чтобы страница, CSV и памятка оставались согласованными; созданные файлы для посетителей вы не редактируете.
Проверьте и опубликуйте это изменение исходного кода:
git --no-pager diff -- event.properties
git add event.properties
git commit -m "Move the garden meeting to 10:30"
git push origin garden-plan
Различия должны менять только это время встречи. Если это не так, исправьте файл до коммита. Ветка реки не получает изменений исходного кода.
Переключитесь в Jenkins, вернитесь в community-previews и выберите Scan Multibranch Pipeline Now. После индексирования задание сада должно запустить новую сборку изменённой ревизии; неизменённая ветка реки должна сохранить записанный вами номер сборки. Дождитесь завершения сборки сада с SUCCESS. Откройте её Console Output и соотнесите новый коммит и 10:30 с изменением исходного кода.
Если сканирование сообщает об отсутствии изменений, а предварительная версия сада остаётся старой, вернитесь в Source. Проверьте git status --short и git --no-pager log -1 --oneline, убедитесь, что нужное изменение закоммичено в garden-plan, и отправьте эту ветку перед новым сканированием. Локальная правка файла или коммит, ещё не достигший origin, пока не является исходным кодом, который может обнаружить Jenkins. Если сборка неуспешна, прочитайте её консольный вывод и исправьте указанную ошибку исходного кода новым коммитом и отправкой. Не сбрасывайте виртуальную машину и не заменяйте предоставленное средство сборки.
Переключитесь в Preview Desk и обновите страницу. Откройте garden-plan: теперь встреча Garden Gathering должна быть в 10:30. Изучите Explore this plan, скачанный CSV мероприятий и полную памятку для посетителей; время встречи должно совпадать везде. Откройте river-plan: встреча Riverside Picnic по-прежнему должна быть в 14:00, с исходными мероприятиями и работающими вложениями. Её build.json должен сохранять предыдущий исходный коммит и собственный номер сборки Jenkins. Не перезапускайте это неизменённое дочернее задание во время последнего обновления.
Вернитесь в Jenkins и скачайте новейший preview.zip сада. Распакуйте его в ещё одну новую папку и повторите локальные проверки страниц, изображения, CSV и памятки. Он должен указывать новый коммит сада; скачанный ранее комплект реки должен оставаться пригодным для независимого использования.
Наконец, вернитесь в Preview Desk, откройте Open the official program и Read the courtyard notes и убедитесь, что обе полные программы остались нетронутыми. Сохраните исходную историю веток и сборок. Если внесёте любое дальнейшее изменение исходного кода, создайте коммит, отправьте его и дождитесь завершения соответствующей сборки Jenkins перед проверкой выполнения. У вас две действующие предварительные версии и свидетельства того, что обновление одной не перезаписало и не пересобрало соседнюю.
Резюме
Вы использовали встроенное обнаружение веток Multibranch и ревизию исходного кода, из которой получен каждый Jenkinsfile, затем разделили публикацию по идентификатору ветки Jenkins. Теперь у обоих планов есть работающие страницы, изображения и вложения по независимым адресам. Последующий коммит плана сада обновил только его предварительную версию, а сборка плана реки, официальная программа и предварительная версия двора остались нетронутыми.
