Назначение labels у всех объектов одинаковое - это предоставление возможности косвенно ссылаться на объекты в кластере, группировать их по определенному признаку (значениям лейблов), использовать из в качестве селекторов. Примером могут быть лейблы указывающие на окружение к которому относится деплоймент (qa, stage и т.п.), версия, api это и консьюмер и т.д. В том числе есть набор стандартных лейблов, вроде указанного в примере app, по которому можно сделать выборку объектов кластера, относящихся к этому app
Делать так, как удобнее.
Например, я бы сделал так:
Один репозиторий с описанием пайплайна в master
От master отводится ветка, в нее коммитится скрипт
Пайплайн отрабатывает по скрипту
После успешного прохождения пайплайна, ветка удаляется (опционально, предполагаю что раз скрипты одноразовые и не версионированы- хранить их в репозитории смысла нет) или вливается в некую ветку archive
В целом, у кеша нет параметра его жизни. Живет до момента его сброса.
Есть лог с причиной инвалидации кеша? Может быть у вас кеш не синхронизируется между раннерами?
У смотрю вас много котов и они чего-то все время хотят.
Да, изменение в названии пакета и групп приводят только к тому, что всем и везде придётся эти пути обновить. При этом гитлаб довольно добрый и по старым путям проект останется доступен (не знаю как долго) и гитлаб при каждой операции будет указывать на то, что необходимо обновить урлы.
Docker compose хорошо подходит для локального применения. Во всех других случаях его преимущества совершенно неочевидны.
Сервисы уже собраны и запушены в registry? Тогда просто 1 раз пуллитесь из registry и стартуете все контейнеры пачками, каждый раз генерируя рандомный порт и сеть для набора контейнеров.
Но как вы собираетесь контролировать такой ворох контейнеров? Может вам стоит смотреть в сторону, например, Docker Swarm?
Вы должны сперва выполнить сборку проекта, затем его деплой, а не наоборот. Используйте, например, ansistrano. И в таком случае будет применим и текущий вариант, т.к. лишь в последний момент будет создан линк на новое приложение.
Использование докера так же упрощает жизнь. Подумайте о внедрении его в процесс деплоя и эксплуатации.
Так же теоретические знания по CI, CD и CD. Поверхностно, например: qaat.ru/kakaya-raznica-mezhdu-continuous-delivery-...
1). Инструментов множество, к озвученным могу прибавить Gitlab CI. В разных командах разный набор инструментов, поэтмоу важно понимать именно теорию работы таких систем.
2). Актуальная задача для QA в CI - запуск автотестов после сборки, например,перед мерджем веток. Со стороны QA тут написание автотестов.
Так же понадобится знание bash (скрипты), большим плюсом будет знание какого либо ЯП, например python. Зачастую будет необходимо понимать суть чужого кода на незнакомых ЯП.
Знание Jenkins, и, например, GitlabCI.
Какой-либо системы оркестрирования: ansible, puppet, chief, solt...
Лично у нас деплой через capistrano, но деплой-систкм так же превиликое множество.
У каждой команды будет свой стек инструментов и методик. Нужно приходить в команду и прыгать в этот омут.
Похоже такого функционала не предусмотрено. Но есть варианты, которые можно попробовать.
Текстовые логи хранятся на диске где-то тут: $JENKINS_HOME/jobs/$JOB_NAME/builds/lastSuccessfulBuild/log
Или можно попытаться curlом:
