Прошу консультацию по Gitlab CI
Господа и господамы, а есть ли тут мастера спорта по Gitlab CI? Хочется получить профессиональную консультацию.
Попробую описать вопрос:
представим себе ситуацию, когда разработчик неделю работает локально и что-то там у себя коммитит (но не пушит в гитлаб). И вот, спустя неделю, он решил задачу и решил вывалить свое творение на обозрение, запушив весь свой кодовый понос в отдельную ветку.
И вот тут-то нам бы проверить, чего он там такого понаписал, не наделал ли синтаксических ошибок в спешке, которые сразу положат приложение. Пайплайн запускается, отрабатывает билд зависимостей, запускается линтер и юнит-тесты, и вроде бы все ОК, можно деплоить на дев.. НО! Пайплайн проверил только его последний коммит, в котором он, например, поправил файлик `README.MD`. А предыдущие 10 коммитов, где могут быть ошибки, пайплайн не проверяет.
С одной стороны я могу себе это объяснить тем, что надо заставлять разработчиков пушить каждый коммит в удаленную репу, т.е. гитлаб. Но с другой стороны как это побороть в тех ситуациях, когда разработчик "забыл", "не было связи", "балбес" и т.д.
Аналогичный вопрос касается слияния веток. Берем мы ветку этого разработчика и открываем Merge Request на вливание её в `development`. Если тесты пройдут успешно - можно вывалить его творение на dev-стенд и потестировать. И вот опять беда - гитлаб запускает пайплайн только на последний коммит в MRе, хотя их там может быть сколь угодно много. Пробовал костылить всякие git diff с хешами и ветками, но все не то - показывает обратный дифф, если бы ветку development вливали в его ветку.
Подозреваю, что я чего-то не понимаю, не следую какому-то правильному flow и тд.
Прошу подсказать, объяснить, проконсультировать. Если удобно - можно даже персонально в мессенджере, с оплатой
TRDL: всё ок, так и должно быть. Линтинг и тесты должны проверить состояние всего кода в ветке на момент последнего коммита, разве что это намеренно не было сломано.
Более подробное описание:
Коммиты наслаиваются друг на друга, пайплайн на последнем коммите проверяет итоговое состояние кода на момент этого коммита, т.е. проверено абсолютно всё, что было сделано в этой ветке.
После мержа коммиты из ветки-источника переносятся в целевую ветку, где могут быть коммиты, которых изначально не было у разработчика в его ветке (были помержены после, например).
В этот момент целесообразно повторно прогнать линтинг и тесты. Гитлаб создаст пайплайну по последнему коммиту, но проверка всё равно будет выполнена не только по коммиту, а по всему состоянию ветки в момент запуска.