Автоматизація оновлень залежностей у GitLab CI/CD: Повний посібник - javascript.org.ua

текст перекладу
Управління залежностями — це критичний аспект підтримки здорової кодової бази. Застарілі залежності можуть призвести до вразливостей у безпеці, проблем сумісності та збільшення технічного боргу. GitLab — потужний інструмент для будь-якого процесу CI/CD, і розблокувавши його повний потенціал, ви зможете автоматизувати майже все. Проте багато розробників нехтують цим через проблеми з безпекою або відсутність розуміння синтаксису та можливостей YAML GitLab.

Одна з найцікавіших функцій — це Pipeline Schedules, які дозволяють автоматизувати завдання за допомогою розкладів cron. Це особливо корисно, коли потрібно регулярно оновлювати залежності чи бібліотеки. Незалежно від того, чи використовуєте ви JavaScript (npm пакети), PHP (Composer) або іншу мову, важливо підтримувати вашу технологічну стеку в актуальному стані для стабільності та безпеки. Однак вручну оновлювати залежності може бути часозатратним та схильним до помилок. Автоматизація пропонує надійне рішення для цієї проблеми.

У цьому посібнику ми покажемо вам, як автоматизувати оновлення залежностей для PHP-проекту за допомогою GitLab CI/CD. Ви дізнаєтеся:

Як налаштувати оновлення щомісяця
Як автоматично створювати merge request (MR)
Як безпечно пушити зміни для перевірки

Крок 1: Налаштування базового завдання

У GitLab CI/CD стадії визначають порядок виконання завдань. Створивши стадію оновлення, ми гарантуємо, що завдання оновлення залежностей буде виконано в потрібний момент пайплайну.

Визначення завдання для оновлення

Почніть з визначення простого завдання у вашому файлі .gitlab-ci.yml. Це завдання буде виконувати composer update для оновлення ваших залежностей.

auto update:  
 stage: update  
 image:  
 name: ${IMAGE_PATH}:${IMAGE_TAG}  
 script:  
 - composer update

З цією конфігурацією ви зможете вручну або за розкладом запускати завдання для оновлення залежностей.

І в кінці ви повинні отримати це 👇

Тепер у нас є основа для наступних кроків.

Крок 2: Додавання автоматизації Merge Request

Автоматизація створення Merge Requests (MR) гарантує, що кожне оновлення залежностей буде перевірено і протестовано перед тим, як бути об'єднаним в основну гілку. Цей процес покращує якість коду і знижує ризик внесення руйнівних змін.

Ось як це зробити крок за кроком:

Створіть нову гілку

Спочатку створіть унікальну гілку для кожного оновлення, щоб ізолювати зміни:

variables:  
 NEW_BRANCH: "feature/auto-branch-$CI_PIPELINE_ID"  

auto_update:  
 stage: update  
 image:  
 name: ${IMAGE_PATH}:${IMAGE_TAG}  
 script:  
 - git config user.email "[email protected]"  
 - git config user.name "CI Bot"  
 - git checkout -b $NEW_BRANCH  
 - composer update

Зробіть commit змін

Після виконання composer update, зробіть commit оновлених залежностей:

- git commit -a -m "Automatic package update from CI"

Push змін і відкриття MR

Щоб запушити гілку і створити merge request, вам потрібен access token. Цей токен може бути специфічним для проекту або для всього робочого простору. Хоча останній варіант дає ширший доступ, він менш безпечний. Вибирайте залежно від ваших потреб.

Створення Access Token

Перейдіть в Settings > Access Tokens у вашому проекті GitLab.
Створіть новий токен з правами write_repository.
Порада з безпеки: Зберігайте цей токен безпечно за допомогою змінних CI/CD GitLab (наприклад, WRITE_TOKEN).

Створення access token

Надайте токену права на запис.

Вибір scope

Є деякі обмеження, які слід врахувати — ви не можете пушити зміни в будь-який репозиторій.
текст перекладу
Ви повинні переконатися, що токен завдання (job token) явно дозволений у налаштуваннях вашого проєкту.

Надання дозволів проєкту для будь-якого токену

Оновлення віддаленого URL і Push

- git remote set-url origin "https://auto_update:${WRITE_TOKEN}@gitlab.com/$CI_PROJECT_PATH.git"  
- |  
 git push --set-upstream origin $NEW_BRANCH -o merge_request.create -o merge_request.target=${BASE_BRANCH} \  
 -o merge_request.title="Auto generated MR from CI with package updates"

Важливі моменти:

• Безпека Access Token: Переконайтеся, що WRITE_TOKEN зберігається безпечно і має мінімально необхідні права доступу.

• Іменування гілок: Використання унікальних імен для гілок запобігає конфліктам і спрощує відстеження автоматизованих оновлень.

Крок 3: Повна конфігурація YAML

Ось як може виглядати ваш файл .gitlab-ci.yml з автоматизованим створенням MR:

variables:  
 BASE_BRANCH: "main"  
 NEW_BRANCH: "feature/auto-branch-$CI_PIPELINE_ID"  
 GIT_DEPTH: 0  
 GIT_STRATEGY: clone  

auto_update:  
 stage: update  
 image:  
 name: ${IMAGE_PATH}:${IMAGE_TAG}  
 rules:  
 - if: '$CI_PIPELINE_SOURCE =~ /schedule|web/ && $AUTO_UPDATE == "ON"'  
 script:  
 - git config user.email "[email protected]"  
 - git config user.name "CI Bot"  
 - git checkout -b $NEW_BRANCH  
 - composer update  
 - git commit -a -m "Auto update packages from CI"  
 - git remote set-url origin https://auto_update:${WRITE_TOKEN}@gitlab.com/$CI_PROJECT_PATH.git  
 - |  
 git push --set-upstream origin $NEW_BRANCH -o merge_request.create -o merge_request.target=${BASE_BRANCH} \  
 -o merge_request.title="Auto generated MR from CI with package updates"

Зверніть увагу на секцію rules. Це дозволяє ізолювати виконання нашого завдання, визначаючи конкретну змінну. Такий підхід особливо корисний, коли у вас є кілька подібних завдань в одному пайплайні.

Основні особливості цієї конфігурації:

Створення гілки: Для кожного запуску пайплайну створюється нова гілка.
Commit і Push: Зміни комітяться і пушаться безпечно за допомогою токену доступу.
Створення Merge Request: Команда git push включає опції для автоматичного створення MR, що націлений на основну гілку.

Наголос на безпеці:

Access Tokens: Переконайтеся, що токени, як WRITE_TOKEN, зберігаються безпечно у змінних CI/CD GitLab і мають тільки необхідні права доступу.

Крок 4: Тестування та налаштування розкладу пайплайна

Налаштуйте новий розклад.

Новий розклад

Вручну запустіть пайплайн.

Перевірте, що нове завдання було запущене.

MR відкривається автоматично.

Після тестування налаштуйте пайплайн для регулярного запуску. Перейдіть до CI/CD > Schedules в GitLab і налаштуйте щомісячний розклад. Не забудьте об'єднати ваші зміни в основну гілку та оновити налаштування розкладу, щоб вказати основну гілку.

Поради щодо налагодження

Неуспішні завдання: Перевірте логи завдань, щоб виявити помилки.
MR не створено: Переконайтеся, що токен доступу має правильні права і що змінні налаштовані коректно.
Конфлікти гілок: Використовуйте унікальні імена для гілок, щоб запобігти конфліктам.

Підсумки

Вітаємо! 🎉 Ви успішно автоматизували оновлення залежностей в GitLab.
текст перекладу
З таким налаштуванням:

Ваші репозиторії залишатимуться актуальними з мінімальним вручну втручанням.
Кожне оновлення проходитиме через належне тестування та перевірку.
Ви заощадите дорогоцінний час вашої команди, зберігаючи високу якість коду.

Додаткові переваги:

Покращена безпека: Регулярні оновлення допомагають швидко виправляти уразливості.
Стабільне обслуговування: Автоматизовані оновлення гарантують, що залежності постійно підтримуються в актуальному стані у всіх проєктах.

Наступні кроки:

Розширте на інші мови: Хоча цей посібник зосереджений на PHP, подібну автоматизацію можна застосувати й до інших мов, таких як JavaScript (npm), Python (pip) або Ruby (Bundler).
Інтеграція сповіщень: Налаштуйте сповіщення про створення або об'єднання MR, щоб тримати вашу команду в курсі.

Спробуйте, і дайте знати, як це працює для вас! Якщо у вас є поради чи питання, залишайте їх у коментарях нижче.

Успіхів у написанні YAML та не забувайте автоматизувати! 🤖

Перекладено з: Automate Dependency Updates in GitLab CI/CD: A Complete Guide