Как внутренняя работа "страниц" Gitlab?

Question

У меня есть проект Gitlab, как этот (.gitlab-ci.yml):

# Sub-jobs listed as comments
stages:
  - check-in-tests
      # shellcheck
      # pylint
      # unit-tests
  - several-other-things
      # foo
      # bar
      # baz
  - release
      # release

# Run some shell code static tests and generate logs/badges
shellcheck:
  stage: check-in-tests
  script:
    - bash run_shellcheck.sh
  artifacts:
    paths:
      - logs/shellcheck.log
      - logs/shellcheck.svg

# Run some python code static tests and generate logs/badges
pylint:
  stage: check-in-tests
  script:
    - bash run_pylint.sh
  artifacts:
    paths:
      - logs/pylint.log
      - logs/pylint.svg

# <snip>

На моей странице проекта я хотел бы отобразить файлы.svg, созданные во время проверки в виде значков.

Для инструмента значков Gitlab требуется URL-адрес файла изображения. Он не способен загружать изображения из URL-адресов со строками запроса. К сожалению, синтаксис для доступа к определенным артефактам задания заканчивается строкой запроса. Это фактически означает, что мы не можем связывать артефакты работы как значки.

Самый популярный способ - использовать функцию страниц Gitlab для хранения артефактов в виде статического содержимого. Оттуда мы можем получить чистые URL-адреса наших артефактов, которые не содержат строк запроса.

Моя путаница связана с базовым механизмом работы "pages", определенным в.gitlab-ci.yml. Официальная документация здесь очень скудная. Существует миллион примеров развертывания реальной веб-страницы с различными платформами, но я не заинтересован ни в одной из них, поскольку я просто использую "страницу" своего проекта для размещения файлов.

Предполагается, что я хочу развернуть свою страницу в конце конвейера. Тем не менее, я хочу загрузить артефакты shellcheck и pylint в начале конвейера. Кроме того, я хочу, чтобы эти артефакты были загружены, даже если этапы конвейера не пройдены.

Синтаксически работа страниц выглядит идентично любой другой работе. Там нет ничего, чтобы описать, как это волшебно подхвачено внутренностями Gitlab. Это оставляет меня со следующими вопросами:

• Могу ли я изменить стадию "развертывания" на "проверку в тестах", или стадия развертывания является частью скрытой магии, которую ищет Gitlab при разборе задания страницы?
• Если я привязан к этапу развертывания, могу ли я перестроить этапы так, чтобы он проходил раньше в конвейере, не разрушая магию?
• Размещает ли задание страниц артефакты с локального компьютера (поведение задания по умолчанию), или перечисленные пути исходят от артефактов, которые уже были загружены в конвейер Gitlab более ранними заданиями?
• Если задание страниц ищет артефакты только локально, как я могу убедиться, что оно выполняется на том же компьютере, что и предыдущие задания, чтобы найти обнаруженные ими артефакты? Предположим, что все исполнители Gitlab происходят из пула с одним и тем же тегом и не помечаются индивидуально.
• Есть ли шанс заставить задание страниц работать в том же контейнере Docker, который изначально создавал артефакты?

Answer 1

Волшебство вокруг страниц GitLab заключается в названии работы. Это должно быть названо "страницы", и ничего больше. Возможно перенести работу на разные этапы. Как только задание "страницы" успешно завершено, появляется специальный тип задания, который называется "страницы: развертывание". Это задание отображается на этапе развертывания, даже если вы измените этап, на котором выполняется задание "страницы".

Если у вас есть задание страниц на ранней стадии, задания на более поздних стадиях могут потерпеть неудачу, но задание "pages: deploy" все равно будет запускаться и обновлять страницы GitLab.

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

https://docs.gitlab.com/ee/ci/yaml/

Задание "pages" должно создать папку с именем "public" и предоставить эту папку в качестве артефакта.