Skip to content

Latest commit

 

History

History
139 lines (94 loc) · 6.88 KB

questions.md

File metadata and controls

139 lines (94 loc) · 6.88 KB
Raw
  1. Как разделить сборку и тесты и деплой на разные pipelines ?
Ответ Прописать в начале .gitlab-ci.yml:

stages:

  • build

  • test

  • deploy
    В описание самой сборки указать например stage: build

  1. Как настроить выполнение сборки тестов или деплоя из определенной ветки?
Ответ Прописать

only: - name branch

  1. Как запускать сборку из одного .gitlab-ci.yml но на разных серверах?
Ответ Регистрируем ранера с тегом name-tag

В .gitlab-ci.yml прописываем в описании

tags: - name-tag

  1. Как выполнить какую то команду перед выполнением задания?
Ответ Прописать before_script: 
- name command
  1. Как прописать команду которую выполнит сам бегунок?
Ответ Прописать script: 
- name command
  1. Как сделатьтак что бы pipelines запускалиль руками а не автоматически?
Ответ Прописать when: manual. По умолчанию стоит when: on_success.
  1. Как настроить задачу сборки кода, только при merge request?
Ответ Настроить задачу сборки кода, добавив правило срабатывания только при merge request:

build job:

script:

- name-command

tags:

- name-tag

stage: build

only:

- merge_request
  1. Как настроить задачу сборки кода, только если создан merge request с определённой целевой или исходной веткой?
Ответ rules: 
- if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"
  1. Как настроить задачу так что бы использовать уже ранее созданные артефакты?
Ответ Для этого нужно в конфигурацию задачи добавить пути, файлы по которым нужно будет сохранить и переиспользовать в следующих задачах, в ключ artifacts:

Например:

build job:

artifacts:

paths

  - nameartifacts или /dir/nameartifacts
  1. Как сдлелать так что бы одни и теже зависимости не загружались постоянно увеличивая время pipeline?
Ответ Прописать например:

cache:

key: name-${CI_COMMIT_REF_SLUG}

paths:

- node_modules

Где ${CI_COMMIT_REF_SLUG}– переменная окружения, которую создает гитлаб. В ней хранится хеш имени ветки, в которой запущен процесс.

Это будет работать следующим образом: каждый раз при запуске задачи гитлаб будет искать у себя сохраненный кеш с названием, совпадающим с name-хеш_ветки. Если найдет — скачает его и добавит к кодовой базе, на которой будут совершаться дальнейшие действия. В данном случае скачает все node_modules, которые сохранились с предыдущего запуска и после выполнения стандартного шага npm i установка зависимостей произойдет гораздо быстрее.

  1. Разница между cache: и artifacts: ?
Ответ Кеш, исходя из названия, нужен для того, чтобы что-то временно хранить для ускорения сборки. Кстати, исходя из его предназначния, гитлаб не гарантирует то, что кеш найдется, он вполне себе может потеряться.

У кеша мы можем указать ключ, а у артефактов — не можем. Это происходит потому, что кеш шарится между несколькими пайплайнами, можно запустить сборку ветки два раза, и они будут использовать один и тот же кеш (потому что название ветки, на которое мы ссылаемся в ключе — одинаковое).

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

Артефакт можно скачать из интерфейса гитлаба — все пакуется в zip и доступно для скачивания и анализа (удобно дебажить проблемы с node_modules). У кеша такой опции нет. Если смотреть чуть глубже, то кеш хранится на там, где установлен раннер, а артефакт — у самого гитлаба. Это как раз и обеспечивает гарантию наличия/отсутствия кеша и артефактов. Кстати, можно настроить и хранить артефакты до 30 дней.

Но в итоге непонятно: как тут добавление артефактов позволяет деплоить pages, и когда вообще нужно их использовать?

Деплой pages происходит просто потому, что гитлаб придумал такой алгоритм — если в артефактах папка public — она используется для раздачи статики. Вот и вся хитрость

Артефакты же нужно использовать когда нужно передать какие-то данные между этапами сборки. Например, в одном этапе собрали бандл фронтовый, и в качестве артефакта передали его на этап деплоя.