Ответ
Поддержка форка сторонней роли Ansible — это баланс между получением обновлений от сообщества и сохранением своих кастомных изменений. Я выстроил следующий процесс:
1. Структура и версионирование.
Я явно указываю форк в requirements.yml, фиксируя его на конкретном коммите (теге или хэше), а не на ветке. Это гарантирует воспроизводимость.
# requirements.yml
- src: git+https://github.com/my-org/ansible-role-nginx.git
version: "a1b2c3d" # Конкретный хэш коммита
name: nginx_custom2. Связь с апстримом.
В локальном репозитории роли я добавляю удаленный репозиторий (upstream) оригинального автора.
git remote add upstream https://github.com/original-author/ansible-role-nginx.git
git fetch upstream3. Стратегия слияния изменений. Я регулярно просматриваю изменения в апстриме. Если нужны обновления безопасности или важные фичи, я мерджу их в свою ветку, разрешая возможные конфликты. Свои изменения стараюсь держать в отдельных коммитах и логически сгруппированными, чтобы упростить слияние.
4. Минимизация модификаций в форке. Лучшая практика — изменять оригинальную роль как можно меньше. Вместо правки самой роли я:
- Использую переменные для переопределения дефолтных значений.
- Создаю отдельную, более высокоуровневую роль-обертку, которая зависит от форка и добавляет мои таски, хендлеры или шаблоны.
- Если правка все же необходима, тщательно документирую её в README форка.
5. Автоматизированное тестирование.
Для форка настраиваю CI (например, GitHub Actions), который запускает линтер (ansible-lint) и тестовый плейбук на разных дистрибутивах (с помощью molecule и docker). Это помогает быстро выявить проблемы после слияния обновлений из апстрима.