Была изначально задумка и хотя бы про Docker и docker-compose написать, это тоже очень полезно и кучу проблем снимает. Особенно когда фронты могут с беками собрать компоуз чтобы локально сервисы бека поднимать

Но тогда статья увалила бы за читабельное за раз количество символов :)

Спасибо за уточнение!

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

Чтобы не получилось так что первый пайплайн закончит работу после второго — стоит использовать тэги. То есть когда оба MR слиты в мастер — руками запустить джобу которая заинкрементит версию и поставит тэг. Потом все это пушнет — пайплайн уже побежит не для мастера, а для тега. Коллизии быть не должно (если конечно вы не запустите 2 джобы версионирования параллельно, но это уже какойто преднамеренно вредительский кейс)

Я бы делал специализированные теги/ветки (в зависимости от того какой у вас SDLC), на которых бы запускались свои джобы, которые в свою очередь использовали скрипты специфичные для пакета\репозитория

Спасибо за ответ. С заменой контента файла, действительно просто и хорошо. Из арументов у меня осталось лишь то что не апишный вариант будет работать с любым хостингом репозиторием. Но в итоге возвращаемся к тому что было сказано — дело привычки и вкуса :)

:)

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

А есть способ выкусить в подобном формате диф существующего коммита? Потому что кажется появятся телодвижения с форматированием тела для этого запроса. Плюс похоже что прийдется делать 2 запроса: 1 — сам коммит, 2 — тэг (опять же нюансы с формированием тела)