Если вы новичок в GitHub или сообществе с открытым исходным кодом, вы, вероятно, будете незнакомы с большинством терминов, упомянутых в названии этой статьи. Такие фразы оказались очень пугающими для меня при навигации, сделав мой первый вклад в проекты с открытым исходным кодом. Однако позвольте мне заверить вас, что это не так пугающе, как кажется. В этой статье я буду разрушать настройку узла CI через действия GitHub и даст несколько советов о том, как использовать проблемы навигации на GitHub, которые сначала кажутся сложными.
Давайте начнем с понимания значений ключевых терминов.
🔗 Что такое непрерывная интеграция (CI)?
В большинстве крупных проектов, в первую очередь с открытым исходным кодом, несколько разработчиков и участников работают над созданием различных функций и одновременно решают отдельные проблемы. Несмотря на то, что отдельные коды могут работать нормально отдельно, они часто могут вводить конфликты при составлении в проекте и привести к нарушению комбинированного кода. Чтобы избежать таких ситуаций, практика Непрерывная интеграция (CI) возникало, когда разработчики часто интегрируют код в общий репозиторий, предпочтительно несколько раз в день. Автоматизированные сборки и автоматические тесты могут затем проверить каждую интеграцию.
«Непрерывная интеграция не избавляется от ошибок, но это значительно облегчает их поиск и удаление». — Мартин Фаулер, главный ученый, мыслил
Одним из ключевых преимуществ регулярной интеграции кода является то, что они позволяют быстро обнаруживать ошибки и легче найти их. Поскольку каждое введенное изменение обычно невелико, определяя конкретное изменение, которое ввела дефект, может быть сделан быстро.
📑 Что такое действия GitHub?
Когда участник делает запрос на привлечение, существует несколько организационных задач, которые необходимо выполнять со стороны хранилища репозитория. Они включают в себя просмотр запроса на вытяжение, проведение некоторых тестов, проверка, соответствуют ли изменения в стиле кода репо и т. Д. Это пример рабочего процесса разработки программного обеспечения.
Рабочие процессы состоит из одной или нескольких заданий и могут быть запланированы или вызваны событием, в данном случае, выполняя запрос на вытяжение.
По мере того, как проект становится все больше и накапливает больше авторов, проблем и запросов, он требует больших организационных усилий для его поддержания. Следовательно, сопровождающие, естественно, хотят автоматизировать большинство этих задач, что возможно с помощью действий GitHub.
Действия GitHub помогают вам определить набор действий, которые будут выполняться автоматически в ответ на события, происходящие в или на ваш репозиторий.
💻 Начало работы с действиями GitHub
Каждый репозиторий GitHub имеет Действия Вкладка, которая указана ниже.
Как только вы перемещаетесь в Действия Вкладка, вы увидите несколько шаблонов рабочего процесса. Как правило, есть четыре категории, которые показаны ниже. Вы можете выбрать предлагаемый рабочий процесс или прокрутить вниз до рабочих процессов непрерывной интеграции, чтобы выбрать один на основе технического стека, используемого в проекте.
Как только вы найдете подходящий шаблон, нажмите на Установите этот рабочий процесс Анкет
👩💻 Настройка рабочего процесса
При выборе шаблона файл .yml будет создан в каталоге/.github/workflows вашего хранилища кода. Каждое действие GitHub требует .yml (Ямл не является языком разметки) Файл. YAML-это язык сериализации данных, читаемый на человеке, обычно используемый для Файлы конфигурации и приложения, где данные хранятся или передаются.
Теперь вы можете настроить рабочий процесс в соответствии с вашими требованиями.
Давайте возьмем пример проекта узла, в котором мы хотим автоматизировать выполнение следующих шагов каждый раз, когда выполняется запрос на тягу:
- Установите зависимости узла
- Запустите Linter, чтобы проанализировать код для потенциальных ошибок
- Убедитесь, что изменения соответствуют стилю кода репо.
Наш файл .yml должен выглядеть примерно так.
Давайте попробуем понять содержимое этого файла шаг за шагом.
name: Node CI
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install dependencies
run: npm install
- name: Linter
run: npm run lint
- name: Prettier Format
run: npm run format
Имя [необязательно] — используется для описания того, что делает рабочий процесс
на — перечисляет события, которые запускают рабочий процесс. В этом случае действия запускаются, когда кто -то выдвигает код непосредственно в репозиторий или когда выполняется запрос на тягу. Вот Список всех событий который может вызвать рабочие процессы.
Работа — Этот раздел используется для определения действий, которые будут выполняться в ответ на вышеупомянутые события.
- Там может быть несколько последовательностей задач, вложенных в соответствии с заданиями. Каждая последовательность определяется именем, в данном случае это «Build» Анкет Это имя может быть произвольным, как и название рабочего процесса.
- Runs -on — Определяет, на какую виртуальную машину должны работать задание. Мы запускаем это на Ubuntu, но вы также можете выбрать Windows или Mac-OS.
- шаги — Определяет последовательность инструкций, которые создают и проверяют наш код
- Использование: действия/проверка@v2 — Эта строка приносит наш исходный код в виртуальную машину, используя Официально поддерживается действие под названием Checkout Анкет Это позволяет запускать команды в коде, аналогичный тому, как вы тестируете код из командной строки при работе над каталогом в вашей локальной машине.
- использует Ключевое слово позволяет использовать любой предопределенный набор действий
- Каждый шаг требует имя и запустить Ключевое слово, чтобы определить команду, которая будет выполнена на этом шаге
- В этом случае мы определили три шага для установки зависимостей, запуска Linter и обеспечения соблюдения стиля кода. Вы можете настроить шаги для автоматизации команд для тестирования вашего кода, просто назначить имя и введите команду.
Ты закончил! Теперь каждый раз, когда вы настаиваете на проекте, команды будут автоматически отключаться.
✅ Тестирование рабочего процесса
Идите вперед и сделайте запрос на привлечение в репозитории, чтобы проверить, как работают действия GitHub. Вы увидите что -то подобное, что указывает на то, проходит ли недавно нажатый код все проверки.
Если проверки не сняты, вы можете щелкнуть Детали кнопка. Вы сможете увидеть, что именно пошло не так, и в этот момент, как показано ниже.
Теперь вы можете быстро решить проблему и выдвинуть обновленный код. Зеленый отметок указывает, что ваш код проходит тесты, установленные в CI.
📝 Заключение
Я надеюсь, что тема этой статьи больше не кажется слишком пугающей. Вы можете столкнуться с проблемами намного сложнее, чем эта, но стратегия проста. Если вы не понимаете, что требует конкретной проблемы, вы, Изучите каждый термин и понимайте его значение Анкет Как только вы узнаете, что нужно немного лучше, но не знаете, как это решить, Попробуйте найти блоги, видео или учебные пособия, связанные с задачей Анкет Если что -то все еще неясно, не стесняйтесь Спросите сообщество о помощи Отбросив комментарий. Чаще всего кто -то обязательно вернется к вашему запросу.
Я надеюсь, что этот блог каким -то образом помог вам. Если у вас есть какие -либо другие вопросы, не стесняйтесь бросить комментарий ниже.
Удачи и счастливого кодирования! 😃
Дополнительные ресурсы
- https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions
- https://www.youtube.com/watch?v=R8_veQiYBjI
- https://www.youtube.com/watch?v=eB0nUzAI7M8
- https://dev.to/waylonwalker/what-are-github-actions-1lhh
Оригинал: «https://dev.to/rachita_saha/how-to-configure-continuous-integration-through-github-actions-459o»