Мы не нашли способов, как обойтись без коммитов при отладке. Но своеобразный "debug mode" мы все же придумали:
Создать отдельную ветку для отладки экшенов в духе actions-dev
Редактировать флоу прямо на сайте Github. Тогда не придется заниматься рутинными вещами: придумывать имя коммита, пушить его. Открыли, поправили пару-тройку строк, сохранили (формально, конечно, это коммит). Затем можно будет будет схлопнуть все коммиты в один через Squash and merge.
Добавить в триггеры для отлаживаемого флоу такой код:
on:
push:
branches: [ actions-dev ]
Это заставит Github начать выполнение флоу каждый раз при изменении экшена.
Признаться, нам еще очень далеко до такой ситуации. На сегодняшний день мы не расходуем и 1/3 от того лимита, который Github предоставляет бесплатно.
Но лучше, конечно, поглядывать на лимиты и использование Github Actions, чтобы такой сценарий не возник внезапно. А если уже возник - можно перейти на платную модель использования или потратить какое-то количество времени, чтобы развернуть новую сборку вручную.
Распишу пару пунктов, которыми мы руководствовались при поиске решения для автоматизации создания бэкапов:
Нам, как молодому стартапу, очень важно поддерживать "мобильность" сервера. Запуск скрипта на сервере по расписанию самого сервера - еще одна дополнительная подвязка (хоть и минимальная) к конкретной машине, которую, в случае смены машины, важно не забыть перенести.
Удобно, когда историю работы всех процессов автоматизации можно видеть в одном окне. Если что-то пойдет не так при создании бэкапов - Github влепит в историю запусков ошибку, покажет логи работы скрипта, сообщит о проблеме на email.
Мы действительно запускаем этот же флоу перед публикацией нового релиза. Но раз Github Actions дал возможность запуска и по расписанию - решили не отказываться :)
Мы рассматривали различные варианты. Кажется, AppVeyor попадал в поле зрения, но в бесплатном пакете у него только public-репозитории, а платные варианты мы на тот момент времени не рассматривали. Благо, Github Actions в бесплатном пакете нам дал все, что было необходимо.
каждый постановщик (например, QA или продакт) должен знать о том, как внутри работает фича, и дать краткий овервью по ней?
Не совсем. Я говорил о том, что из тикетов можно убрать сленговые речи, оставив только конкретику. К примеру, фразу «Пользователь %username% апнул свои рулы до модера без пэймента и тем самым попал в moderators_list» можно расписать как «Пользователь %username% смог поднять собственные привилегии до модератора без оплаты и попал в таблицу moderators_list». Так хоть и немного дольше расписывать, но и новичку будет многое понятно и без Quick Start.
Хотя полностью соглашусь с вами в том, что новичок должен освоить основные рабочие процессы, в особенности — собственной команды.
Про тест — признаю, погорячился =) Спасибо за ответ!
Спасибо, было интересно прочитать.
Проблема может во многом решиться, если тестировщики/модераторы и прочие сотрудники будут отсылать грамотные тикеты, описывая проблему в нескольких предложениях. Либо же собрать свою систему тикетов с подключенным wiki. Банально подставлять под некоторые термины соответствующие статьи и определения на wiki. На разворачивание такой системы, имхо, ушло бы не больше времени, чем на написание тестов для закрепления Quick Start.
Мы не нашли способов, как обойтись без коммитов при отладке. Но своеобразный "debug mode" мы все же придумали:
Создать отдельную ветку для отладки экшенов в духе
actions-devРедактировать флоу прямо на сайте Github. Тогда не придется заниматься рутинными вещами: придумывать имя коммита, пушить его. Открыли, поправили пару-тройку строк, сохранили (формально, конечно, это коммит). Затем можно будет будет схлопнуть все коммиты в один через
Squash and merge.Добавить в триггеры для отлаживаемого флоу такой код:
on:push:branches: [ actions-dev ]Это заставит Github начать выполнение флоу каждый раз при изменении экшена.
Нам этого хватило более чем. Но если в ходе отладки возникают сложности - можно включить детальный журнал отладки: https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging . Честно говоря, пока он нам не понадобился.
Спасибо :)
Признаться, нам еще очень далеко до такой ситуации. На сегодняшний день мы не расходуем и 1/3 от того лимита, который Github предоставляет бесплатно.
Но лучше, конечно, поглядывать на лимиты и использование Github Actions, чтобы такой сценарий не возник внезапно. А если уже возник - можно перейти на платную модель использования или потратить какое-то количество времени, чтобы развернуть новую сборку вручную.
Отличное замечание, спасибо!
Распишу пару пунктов, которыми мы руководствовались при поиске решения для автоматизации создания бэкапов:
Нам, как молодому стартапу, очень важно поддерживать "мобильность" сервера. Запуск скрипта на сервере по расписанию самого сервера - еще одна дополнительная подвязка (хоть и минимальная) к конкретной машине, которую, в случае смены машины, важно не забыть перенести.
Удобно, когда историю работы всех процессов автоматизации можно видеть в одном окне. Если что-то пойдет не так при создании бэкапов - Github влепит в историю запусков ошибку, покажет логи работы скрипта, сообщит о проблеме на email.
Мы действительно запускаем этот же флоу перед публикацией нового релиза. Но раз Github Actions дал возможность запуска и по расписанию - решили не отказываться :)
Мы рассматривали различные варианты. Кажется, AppVeyor попадал в поле зрения, но в бесплатном пакете у него только public-репозитории, а платные варианты мы на тот момент времени не рассматривали. Благо, Github Actions в бесплатном пакете нам дал все, что было необходимо.
Не совсем. Я говорил о том, что из тикетов можно убрать сленговые речи, оставив только конкретику. К примеру, фразу «Пользователь %username% апнул свои рулы до модера без пэймента и тем самым попал в moderators_list» можно расписать как «Пользователь %username% смог поднять собственные привилегии до модератора без оплаты и попал в таблицу moderators_list». Так хоть и немного дольше расписывать, но и новичку будет многое понятно и без Quick Start.
Хотя полностью соглашусь с вами в том, что новичок должен освоить основные рабочие процессы, в особенности — собственной команды.
Про тест — признаю, погорячился =) Спасибо за ответ!
Проблема может во многом решиться, если тестировщики/модераторы и прочие сотрудники будут отсылать грамотные тикеты, описывая проблему в нескольких предложениях. Либо же собрать свою систему тикетов с подключенным wiki. Банально подставлять под некоторые термины соответствующие статьи и определения на wiki. На разворачивание такой системы, имхо, ушло бы не больше времени, чем на написание тестов для закрепления Quick Start.