На взгляд автору стоит поиграть в HoMM IV, там многие из этих проблем были решены еще 20 лет назад + добавлено многое из того, что в другие части так и не перекочевало. Можно немного пройтись по пунктам и посмотреть: 1. Решено в четверке через общий лимит на героев/армии, разведку можно делать существами, цепочки в привычном виде не работают, потому что и юниты имеют лимит мувпойнтов - их гораздо сложнее таскать между героями 2. Про рутинные действия это как по мне как раз стратегическая основа игры - можно не собирать и верить что банков на ресурсы или рынков хватит, иначе это превратится в простое линейное прохождение карты по точкам. Опять же,HoMM IV отчасти решает это через караваны с удаленных двеллингов существ + здания, дающие ресурс/золото каждую неделю, делают это автоматически 3. Но ведь в этом и смысл стратегии, в идеальной карте вообще нельзя сидеть в обороне, потому что каждая новая область приносит больше бенефитов (это отражается даже в цели для завершения большинства карт - захватить вражеские замки) 4. Опять же пункт про экспансию, если ты захватил важную точку на карте(например город с доступом к шахтам и тд), то вполне справедливо, что в него нужно вкладывать деньги для удержания. HoMM IV это косвенно решает тем что построек в замке нужно сильно меньше 5. Так же это появилось еще в четверке, но все равно это не приносит сильно большого разнообразия, потому что все так же остается стратегия “вейтимся своим быстрым юнитом, ждем пока мили врага подбежит, летим в стрелков” 6. Тут все немного сложнее, потому что с увеличением разнообразия скиллов сильно усложняется баланс игры (достаточно посмотреть на проблематику балансировки спецов по навыкам в HoMM3). Четверка тут предлагает в основном процентые бонусы (+ уровень изучаемых заклинаний привязан к уровню навыка), но при этом на маленьких картах герой-варвар может убить врага пока маги не успеют раскачаться, а герой-тактик невероятно усиляет армию на длинных картах. 7. На мой взгляд такие изменения просто убьют разнообразие адаптации к игре - почти всегда можно будет собрать набор правильных и нужных тебе заклинаний. Текущая же ситуация опять же подталкивает к экспансии - в городе сдало плохую магию - бери следующий и верь в удачу. 8 и 9. Это выглядит как какое то убийство героев-бойцов, которых в таком случае будут просто сносить магией и без возможности полноценного ответа. Представим бой бойца и мага с такими изменениями: зачастую боец может убить армию мага за 2-3 раунда, поэтому врывается вперед, понимая что либо маг будет замедлять либо наносить урон, но не оба сразу. А с предлагаемыми изменениями маг просто будет сидеть в обороне, ведь у него преимущество и по мане и по заклинаниям и по действиям. 10. Опять выглядит как линеаризация игры. Там где раньше нужно было анализировать лучшее действие в конкретной ситуации будет просто “жмем все подряд, а там увидим” 11 и 12. Здесь как раз подход HoMM3 5 весьма красив - строй таверны, смотри самого сильного героя оппонента, и пыытайся понять будет ли он драться им, это как раз то, что от игрока тактически спрятано через туман войны. Ну и соотвественно требует делать билды, которые работают универсально, а не в зависимости от того, что там у оппонента. + Герои это игра с неполной информацией, поэтому ее получение - одна из основных механик игры. 13. Тут особо сказать нечего, но непонятно как балансить предлагаемые карты с учетом наличия летающих юнитов и того факта, что у разных замков эти юниты в разных тирах (= стеки обладают разной ударной мощью) 14. Помимо роли прикрышки, у единичек есть и другая очень важная роль - снятие ответного удара. Без этого армия героя будет таять на каждом бою, что очень сильно замедлит развитие.
когда говорим про variables, я бы сразу добавлял про inputs, гитлаб их активно продвигает как альтернативу variables, объявленных на уровне всего пайплайна. Inputs нельзя менять в ходе выполнения пайплайна, зато у них есть встроенные возможности для валидации, такие как строгое задание доступных значений или типа значения.
В rules:changes, как и во многих других местах, недоступен т.н. negative regex match. Соответственно нельзя написать рул, который будет по regex исключать job, когда изменились только несущественные файлы (например не запускать сборку если изменился только README.MD, но запускать если изменились и существенные и несущественные).
В статье неявно сказано, но я бы отдельно уточнил, что скрипт в before_script будет смержен с основным script, в отличии от after_script, который будет запущен независимо.
Файл должен называться строго .gitlab-ci.yml и находиться в корне репозитория.
Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен. Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.
На взгляд автору стоит поиграть в HoMM IV, там многие из этих проблем были решены еще 20 лет назад + добавлено многое из того, что в другие части так и не перекочевало. Можно немного пройтись по пунктам и посмотреть:
1. Решено в четверке через общий лимит на героев/армии, разведку можно делать существами, цепочки в привычном виде не работают, потому что и юниты имеют лимит мувпойнтов - их гораздо сложнее таскать между героями
2. Про рутинные действия это как по мне как раз стратегическая основа игры - можно не собирать и верить что банков на ресурсы или рынков хватит, иначе это превратится в простое линейное прохождение карты по точкам. Опять же,HoMM IV отчасти решает это через караваны с удаленных двеллингов существ + здания, дающие ресурс/золото каждую неделю, делают это автоматически
3. Но ведь в этом и смысл стратегии, в идеальной карте вообще нельзя сидеть в обороне, потому что каждая новая область приносит больше бенефитов (это отражается даже в цели для завершения большинства карт - захватить вражеские замки)
4. Опять же пункт про экспансию, если ты захватил важную точку на карте(например город с доступом к шахтам и тд), то вполне справедливо, что в него нужно вкладывать деньги для удержания. HoMM IV это косвенно решает тем что построек в замке нужно сильно меньше
5. Так же это появилось еще в четверке, но все равно это не приносит сильно большого разнообразия, потому что все так же остается стратегия “вейтимся своим быстрым юнитом, ждем пока мили врага подбежит, летим в стрелков”
6. Тут все немного сложнее, потому что с увеличением разнообразия скиллов сильно усложняется баланс игры (достаточно посмотреть на проблематику балансировки спецов по навыкам в HoMM3). Четверка тут предлагает в основном процентые бонусы (+ уровень изучаемых заклинаний привязан к уровню навыка), но при этом на маленьких картах герой-варвар может убить врага пока маги не успеют раскачаться, а герой-тактик невероятно усиляет армию на длинных картах.
7. На мой взгляд такие изменения просто убьют разнообразие адаптации к игре - почти всегда можно будет собрать набор правильных и нужных тебе заклинаний. Текущая же ситуация опять же подталкивает к экспансии - в городе сдало плохую магию - бери следующий и верь в удачу. 8 и 9. Это выглядит как какое то убийство героев-бойцов, которых в таком случае будут просто сносить магией и без возможности полноценного ответа. Представим бой бойца и мага с такими изменениями: зачастую боец может убить армию мага за 2-3 раунда, поэтому врывается вперед, понимая что либо маг будет замедлять либо наносить урон, но не оба сразу. А с предлагаемыми изменениями маг просто будет сидеть в обороне, ведь у него преимущество и по мане и по заклинаниям и по действиям.
10. Опять выглядит как линеаризация игры. Там где раньше нужно было анализировать лучшее действие в конкретной ситуации будет просто “жмем все подряд, а там увидим”
11 и 12. Здесь как раз подход HoMM3 5 весьма красив - строй таверны, смотри самого сильного героя оппонента, и пыытайся понять будет ли он драться им, это как раз то, что от игрока тактически спрятано через туман войны. Ну и соотвественно требует делать билды, которые работают универсально, а не в зависимости от того, что там у оппонента. + Герои это игра с неполной информацией, поэтому ее получение - одна из основных механик игры.
13. Тут особо сказать нечего, но непонятно как балансить предлагаемые карты с учетом наличия летающих юнитов и того факта, что у разных замков эти юниты в разных тирах (= стеки обладают разной ударной мощью)
14. Помимо роли прикрышки, у единичек есть и другая очень важная роль - снятие ответного удара. Без этого армия героя будет таять на каждом бою, что очень сильно замедлит развитие.
Какие то такие мысли, готов еще подскутировать :)
Немного дополнений, возможно кому-то окажутся полезными:
Из workflow рулов часто еще бывает полезно не запускать пайплайн на ветке при пуше в нее, если есть MR с этой веткой
когда говорим про variables, я бы сразу добавлял про inputs, гитлаб их активно продвигает как альтернативу variables, объявленных на уровне всего пайплайна. Inputs нельзя менять в ходе выполнения пайплайна, зато у них есть встроенные возможности для валидации, такие как строгое задание доступных значений или типа значения.
В rules:changes, как и во многих других местах, недоступен т.н. negative regex match. Соответственно нельзя написать рул, который будет по regex исключать job, когда изменились только несущественные файлы (например не запускать сборку если изменился только README.MD, но запускать если изменились и существенные и несущественные).
В статье неявно сказано, но я бы отдельно уточнил, что скрипт в before_script будет смержен с основным script, в отличии от after_script, который будет запущен независимо.
Как будто бы уже довольно давно и название не обязательно такое, и лежать файл может во вложенных папках или вообще в другом проекте - https://docs.gitlab.com/ci/pipelines/settings/#specify-a-custom-cicd-configuration-file. Ключевым отличием будет то, что если файл конфигурации находится вне репозитория, то pipeline editor будет недоступен.
Про него кстати в этом части не заметил упоминаний, хотя он позволяет валидировать конфигурацию и избегать многих синтаксических ошибок. Ну и дает больше представления о происходящем при использовании инклюдов, особенно для компонентов, которые имеют inputs, и нужно соблюдать нейминг.