В этой статье я расскажу, как я подошел к изучению рабочего процесса GitHub и непрерывной интеграции. Во-первых, я пробую новые эффективные шаги для определения требований и решений. Затем я повторяю два, пока не найду полное решение.

Краткое содержание

У меня возникла идея форматировать код на CI — Continuous Integration. Сначала я написал требования. Затем я хотел проверить, отформатирован ли код. Мне нужны были последовательные проверки форматирования для нового кода. CI позаботится о том, чтобы они запускали любого, кто нажимает код. Позже я начал читать о рабочих процессах GitHub. Через четыре часа я прочитал десятки страниц в поисках описания, соответствующего моим требованиям. Я читал еще один час, прежде чем дать ему впитаться. Я начал реализовывать его вечером, и на это ушло около тридцати минут. Установка работала безупречно.

Код формата на ci

Я хотел отформатировать код при непрерывной интеграции. Я знал по опыту. Мне нужно определить, что я хочу сделать. После этого я могу искать способ сделать это.

Определение требований и поиск решения

Определите требования и найдите решение. Повторяйте эти шаги, пока проблема не будет решена. Расплывчатой ​​идеи недостаточно. Следующим шагом стал поиск способа настроить непрерывную интеграцию. Я обнаружил, что могу сделать это с помощью каталога рабочего процесса GitHub и определить набор шагов. Новая проблема заключалась в том, что я не знал шагов. Я снова переопределил требования. На этот раз я был точнее. Я хотел отформатировать код, используя непрерывную интеграцию. Я хочу запустить красивее, чтобы проверить, был ли отформатирован код. Это означает, что мне нужен менеджер пакетов. При этом мне нужно установить пакеты и запустить скрипт. На этот раз я был ближе к решению. Пора искать информацию. Я начал читать о рабочих процессах из документации GitHub. Было много новых терминов, но я не чувствовал себя перегруженным. Это было самым важным. На первой странице упоминался рабочий процесс, задания, этапы, действия и т. д. Я знал, что ищу, поэтому этого было немного. Я обнаружил, что задания выполняются параллельно. Однако шаги внутри задания выполняются последовательно.

Кроме того, я могу определить, что каждое задание может зависеть от предыдущего. Мне не нужна была эта информация, и я продолжил. Я сделал перерыв после нескольких часов обработки информации. Я был уверен, что у меня есть решение. Однако я обнаружил несколько проблем и хотел их решить.

Во-первых, я не знал, каковы были действия GitHub. Зачем они мне нужны? Действия — это набор шагов для настройки задания. Я так их понял.

Во-вторых, я должен проверить свой репозиторий и настроить NodeJS и Yarn. В этот момент я почувствовал себя намного увереннее.

В-третьих, я хотел, чтобы запросы на вытягивание терпели неудачу при сбое CI. Я искал способ сделать это. Я снова был прав. Непрерывная интеграция не делает этого по умолчанию.

Наконец, мне нужно было настроить правило защиты ветки. Открыл правило защиты ветки для проверки, а там ничего не указано. Я понял, что мне нужно активировать рабочий процесс, чтобы добавить его в защиту ветвей. В итоге оказалось, что я был прав.

Позвольте информации проникнуть

Я позволил информации усвоиться, потому что был занят чем-то другим. Я не знаю, помогло ли это. У меня было достаточно короткое время, чтобы реализовать его двенадцать часов спустя.

Реализовать решение

Сначала я добавил проверку и убедился, что она не удалась. Затем я удалил файл и нашел более красивую команду для проверки файлов. Я запустил его, чтобы проверить, отформатирован ли файл, и уведомил меня, что это не так. Результат был таким, как я ожидал. Однако я был подозрительным, потому что он не выдавал ошибок. В более красивой документации упоминается, что он возвращает код 1, если проверка находит неформатированные файлы. Я не знал, почему код возврата актуален. Я просто предположил, что код возврата означает сбой. Ведь в этом его цель. Я зафиксировал эти изменения и описал их цель. Затем я начал писать конфигурацию формата YAML. Я знал, что мне нужно, но не помню синтаксиса.

Во-первых, я добавил поле имени и работы. Затем определите рабочий процесс, который будет выполняться при каждой отправке для любой ветки. Мне не нужна была голая операционная система или так называемый раннер. Во-вторых, я добавил действие, чтобы открыть свой репозиторий и настроить node и Yarn. Я понял, что теперь могу запускать команды. В-третьих, я изменил путь, установил пакеты и запустил команду форматирования. Затем я толкнул ветку, но это не удалось. Оказывается, я не использовал относительный путь для изменения каталога. Я исправил это, и на этот раз это сработало. Проверка непрерывной интеграции не удалась. Это не удалось, потому что файл не был отформатирован. Я запустил команду форматирования и нажал изменения. На этот раз непрерывная интеграция сработала. Пришло время проверить, работает ли это для запросов на вытягивание. Это не сработало, поэтому я вернулся к настройке правила защиты ветки. На этот раз мой рабочий процесс был в списке. После всех этих шагов непрерывная интеграция заработала для запросов на вытягивание и веток. Это было утомительно, потому что я не привык к такому подходу к решению проблем. Я всегда углублялся в код. Я всегда делал беспорядок из-за этого. Наконец, я открыл запрос на извлечение и объединил изменения. Я был удивлен, что мне потребовалось от пяти до семи часов, чтобы написать четырнадцать строк кода. Теперь, когда я думаю об этом, за каждой строкой кода скрывается так много информации.

Основные выводы

Основные выводы:

  • Потратьте время на определение требований
  • Прочтите, чтобы найти элегантные решения для требований
  • Ищите каждую деталь, которая может повлиять на реализацию

Четко сформулированные требования помогли мне сохранить ясность ума. Чтение огромного количества текста утомляет. Тем не менее, я не чувствовал себя подавленным ни в одном из моментов. Я считаю, что это потому, что я уточнил требования. Это как в метафорах. Если вы знаете, что ищете, вы это найдете.

Чтение, чтобы найти элегантные решения, означает, что описание решения хорошо соответствует нашей определенной проблеме. Поэтому я знал, когда нашел то, что мне было нужно.

Я просмотрел детали, которые могут повлиять на мою настройку непрерывной интеграции. Я узнал, как настроить Yarn, но увидел возможность кэширования. Я понял, что это может помешать моему решению. Я посмотрел, и оказалось, что я был прав. Это ускоряет настройку непрерывной интеграции, но мне это не нужно было использовать. У меня был только один пакет, и он быстро установился. Я отбросил этот вариант.

Структура результатов и репозитория

Вот пример структуры и мой репозиторий, который нуждался в ci — sk-экспериментах.

Мне потребовалось несколько часов, чтобы собрать этот файл. Невероятно, правда?

Вот файл. Мне потребовались часы, чтобы исследовать и придумать это. Я хотел знать, что каждая часть внутри него делает. Мне потребовалось несколько часов, чтобы собрать этот файл. Невероятно, правда?