Автоматизация глазами разработчика: Github Actions для стартапа

[gdt]

Проводился ли сравнительный анализ других вариантов (тот же AppVeyor например)?

[mihaill_velicolepniy]

Мы рассматривали различные варианты. Кажется, AppVeyor попадал в поле зрения, но в бесплатном пакете у него только public-репозитории, а платные варианты мы на тот момент времени не рассматривали. Благо, Github Actions в бесплатном пакете нам дал все, что было необходимо.

[chemtech]

Спасибо за пост. Кстати, есть телеграм чат по Github Action https://t.me/github_action_ru

[mihaill_velicolepniy]

Спасибо :)

[debagger]

Статья хорошая. Одно не понял, зачем, чтобы триггерить на своем сервере скрипт по расписанию, нужно использовать Github Actions?

Я бы еще понял, если перед тем, как выкатить новый релиз бэкапы делать. Но так - это похоже на оверкилл.

[mihaill_velicolepniy]

Отличное замечание, спасибо!

Распишу пару пунктов, которыми мы руководствовались при поиске решения для автоматизации создания бэкапов:

1. Нам, как молодому стартапу, очень важно поддерживать "мобильность" сервера. Запуск скрипта на сервере по расписанию самого сервера - еще одна дополнительная подвязка (хоть и минимальная) к конкретной машине, которую, в случае смены машины, важно не забыть перенести.

2. Удобно, когда историю работы всех процессов автоматизации можно видеть в одном окне. Если что-то пойдет не так при создании бэкапов - Github влепит в историю запусков ошибку, покажет логи работы скрипта, сообщит о проблеме на email.

Мы действительно запускаем этот же флоу перед публикацией нового релиза. Но раз Github Actions дал возможность запуска и по расписанию - решили не отказываться :)

[devlev]

Что делать если израсходовал лимит на Github Actions а нужно срочно выложить релиз?

[mihaill_velicolepniy]

Признаться, нам еще очень далеко до такой ситуации. На сегодняшний день мы не расходуем и 1/3 от того лимита, который Github предоставляет бесплатно.

Но лучше, конечно, поглядывать на лимиты и использование Github Actions, чтобы такой сценарий не возник внезапно. А если уже возник - можно перейти на платную модель использования или потратить какое-то количество времени, чтобы развернуть новую сборку вручную.

[debagger]

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

[mihaill_velicolepniy]

Мы не нашли способов, как обойтись без коммитов при отладке. Но своеобразный "debug mode" мы все же придумали:

1. Создать отдельную ветку для отладки экшенов в духе actions-dev

2. Редактировать флоу прямо на сайте Github. Тогда не придется заниматься рутинными вещами: придумывать имя коммита, пушить его. Открыли, поправили пару-тройку строк, сохранили (формально, конечно, это коммит). Затем можно будет будет схлопнуть все коммиты в один через Squash and merge.

3. Добавить в триггеры для отлаживаемого флоу такой код:

   on:

   push:

   branches: [ actions-dev ]

   Это заставит Github начать выполнение флоу каждый раз при изменении экшена.

Нам этого хватило более чем. Но если в ходе отладки возникают сложности - можно включить детальный журнал отладки: https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging . Честно говоря, пока он нам не понадобился.

[Vidatte]

Если речь о том, чтобы запустить action руками, то можно использовать workflow_dispatch.

[Ermak]

Честно говоря, не увидел ничего уникального в ваших скриптах. Все стандартно. И где скрипт восстанавливающий БД из бэкапа?