Я не дублирую файлы, но когда я это делаю, я дублирую стильно
Теоретически при разработке программного обеспечения мы хотим максимально уменьшить дублирование информации и ограничить все до единого источника правды, чтобы улучшить удобство сопровождения.
Однако на практике полностью исключить дублирование практически невозможно, так как системы/фреймворки всегда в чем-то несовместимы.
Возможные ситуации для дублирования
Пример 1
Проекты мобильных приложений могут иметь клиентское приложение и сервер, совместно использующие информацию о версии. Поскольку вполне вероятно, что они созданы с использованием разных технологий, лучшее, что мы можем сделать, — это ограничить информацию о версии клиентского приложения одним источником правды и то же самое для сервера, оставив информацию о версии в двух местах.
Пример 2
Другим примером могут быть файлы README. Репозиторий GitHub обычно имеет файл README верхнего уровня в корне проекта, который отображается на домашней странице репозитория, другой файл находится в папке docs, которая используется для страниц GitHub, и, возможно, третий внутри папки src для сгенерированной документации по API. . Обычно мы хотим, чтобы все 3 были одинаковыми, но из-за ограничений инструментов мы не можем указать все 3 в одном файле, поэтому нам приходится их дублировать.
Можем ли мы упростить обслуживание дубликатов?
Если дублирование — необходимое зло, можем ли мы хотя бы сделать его управляемым?
Во-первых, нам нужно понять, почему дублирование — это плохо.
Наличие нескольких файлов с одинаковым содержимым — это не обязательно кошмар, но проблема возникает, когда разработчикам нужно их обновить.
Хотя копирование файла в несколько мест после изменения не идеально, это не так уж плохо.
Однако катастрофа начинается, когда кто-то забывает продублировать обновления, и они перестают синхронизироваться (что впоследствии часто приводит к неопределенному поведению).
Чтобы решить эту проблему, нам нужен способ всегда синхронизировать дубликаты, и в зависимости от того, как часто они обновляются, лучше использовать автоматизированную систему.
Автоматизация GitHub в помощь
К счастью, с помощью GitHub Action мы можем легко создать автоматизированную систему для синхронизации дубликатов (например, сделать так, чтобы дубликаты были одинаковыми для каждого запроса push или pull).
План состоит в том, чтобы:
- Определите файл конфигурации для описания дублирования.
- Создайте действие GitHub для проверки дубликатов из 1.
- Запускайте действие GitHub при каждом запросе push или pull, чтобы проверить, синхронизированы ли дубликаты.
Разработав высокоуровневую концепцию, давайте переведем ее в код.
Шаг 1: определите файл конфигурации для описания дублирования
Чтобы определить дублирование, нам нужны оригинал и дубликат. Мы можем просто определить пример конфигурации следующим образом:
Приведенная выше конфигурация указывает, что содержимое README.md и docs/README.md всегда должно быть синхронизировано.
Чтобы добавить больше файлов в контрольный список, мы можем создать список, содержащий несколько записей конфигурации, как показано выше.
Шаг 2: создайте докер GitHub Action
GitHub Action может принимать одну из двух форм: либо пакет JavaScript, либо контейнер Docker. Звучит как две совершенно разные технологии, но для целей GitHub Action обе определяют рабочие процессы автоматизации.
Для простоты я выбрал Docker, так как я могу определить всю автоматизацию только с помощью следующего bash-скрипта:
Приведенный выше сценарий считывает содержимое двух файлов, оригинала и дубликата, и сравнивает их на предмет совпадения.
Как вы могли заметить, скрипт использовал GITHUB_WORKSPACE. Это специальная переменная среды GitHub Action, подготовленная для нас, которая представляет собой расположение клона репозитория. Полный список доступных переменных окружения смотрите в документации.
Нам также нужен файл докера-оболочки для запуска скрипта выше:
Шаг 3: идентифицируйте наш код как действие GitHub
После реализации кода для автоматической проверки дублирования нам нужно сообщить GitHub, что это действие GitHub, чтобы мы могли повторно использовать его в проектах/репозиториях.
Мы можем добиться этого, добавив конфигурацию действия action.yml в корень репозитория:
Приведенная выше конфигурация сообщает GitHub, что этот репозиторий содержит действие GitHub с именем «Проверка синхронизации дублирования», которое принимает 2 входных аргумента: оригинал — имя файла источника и зеркало — имя файла дублирования. Кроме того, он указывает, что действие должно быть выполнено путем запуска контейнера, определенного Dockerfile .
Шаг 4: используйте действие GitHub, которое мы создали в рабочем процессе
После создания действия GitHub мы можем использовать его в репозиториях.
Чтобы предложить проекту/репозиторию использовать действие GitHub, нам нужно добавить конфигурацию рабочего процесса:
где tianhaoz95/mirror-action — это репозиторий, в котором размещено действие GitHub, которое мы написали.
После настройки рабочего процесса, как только мы зарегистрируем код, будет запущена проверка синхронизации дублирования, которая выглядит следующим образом:
Спасибо за чтение! Этот пост посвящен тому, как бороться с дублированием с помощью GitHub Actions, но с помощью аналогичных шагов вы можете создать больше автоматизации, которая соответствует вашим потребностям.
Кроме того, если синхронизация дубликатов файлов — это именно то, что вам нужно, это действие доступно по адресу:
И исходный код доступен по адресу:
Присоединяйтесь к FAUN!
Подпишитесь на Темы FAUN и получайте еженедельную порцию обязательных к прочтению технических статей, новостей и руководств🗞️
Подпишитесь на нас в Twitter🐦и Facebook👥и Instagram📷 и присоединяйтесь к нашим Facebook и Linkedin Группы💬
