Руководство по Gitlab-CI

GitLab

Введение в Gitlab CI/CD

Gitlab CI/CD — это инструмент для непрерывной интеграции (CI) и непрерывной доставки (CD), похожие инструменты — Jenkins, Travis CI, GoCD и т. д.

Непрерывная интеграция или непрерывная интеграция — это процесс автоматического обнаружения (анализ кода), сборки и модульного тестирования после изменений исходного кода (git push). Цель непрерывной интеграции — быстро убедиться в том, что новый код разработчиков хорош ( меньше ошибок) и подходит для дальнейшего использования в кодовой базе.

Непрерывная доставка или непрерывная доставка обычно относится ко всей цепочке процессов (конвейеру), которая автоматически отслеживает изменения исходного кода и запускает их через сборку, тестирование, пакетирование и связанные операции для создания развертываемой версии (либо пакет apk, либо развертывание на сайте). , практически без вмешательства человека. Он включает в себя непрерывную интеграцию, непрерывное тестирование (гарантирующее качество кода), непрерывное развертывание (автоматический выпуск версий для использования пользователями).

CI/CD в Gitlab относительно прост: вам нужно только положиться на копию «.gitlab-ci.yml», загрузить файл с кодом, и Gitlab автоматически выполнит соответствующие задачи для достижения CI/CD.

Установка гитлаба

Чтобы использовать функцию Gitlab CI/CD, обычно есть следующие варианты:

  • Во-первых, собрать набор Gitlab самостоятельно, плюс развернуть собственный Runner (то есть машину, которая собственно выполняет код), рекомендуется развернуть docker
  • Во-вторых, используйте фирменный/официальный Gitlab и используйте встроенный Runner, то есть общий Runner, как показано на рисунке ниже.

ссылка на сайт:
nuggets.capable/post/684490…
www.xuxusheng.com/post/Использование док-станции…
docs.git lab.com/runner/Inst…

Gitlab-ci написать

.gitlab-ci.ymlСледуя синтаксису файла YAML, этот файл записывает различные инструкции, которые вы хотите выполнить.Эти инструкции можно использовать для проверки спецификаций (например, PEP8), автоматической упаковки (например, автоматической упаковки Android), автоматического развертывания и т. д. ваш код.

Для новичков, если вы не знаете, что написали.gitlab-ci.ymlЕсть ли ошибка, вы можете использовать встроенный GitlabCI LintПроверять.

Версия, использованная в этой статье:GitLab Community Edition 12.5.6-ee

официальная документация

docs.git lab.com/oh oh/this/нажимаем на дорогу/…

image

Это ключевое слово указывает образ докера, используемый задачей (заданием), напримерimage: python:latestИспользуйте последнее зеркало для Python.

Стратегия зеркальной загрузки:

  • никогда: при использовании этой политики Gitlab Runner будет запрещено извлекать изображения из концентратора Docker или других мест, и можно использовать только изображения, которые вы извлекли вручную.
  • если-не-присутствует: при использовании этой стратегии Runner сначала определяет, есть ли образ локально, если есть, использует образ, если нет, то вытаскивает. Эта стратегия может дать лучшие результаты, если она сочетается с периодическим удалением зеркала.
  • всегда: это стратегия по умолчанию, используемая gitlab-ci, то есть каждый раз, когда зеркало снова сбрасывается, результат требует много времени.

ссылка на сайт:docs.gitlab.com/runner/exec…

services

Это ключевое слово указывает на другие образы Docker, которые будут связаны (ссылкой) на образ, указанный ключевым словом изображения. Например, вы можете связать службу mysql для хранения поддельных данных, необходимых для модульного тестирования.

default_job:
  image: python:3.6

  services:
    - mysql:5.7

  before_script:
    - apt-get install mysql-client

до_скрипта и после_скрипта

Ключевое слово before_script определяет набор команд, которые необходимо выполнить перед запуском каждой задачи, а after_script наоборот. Например, ssh-соединение можно подготовить в before_script, см. ниже.

Примечание: before_script может быть для всех задач или для одной задачи.

Gitlab-CI реализует SSH-соединение

1. Создайте открытый и закрытый ключи, необходимые для SSH. 2. Файл Gitlab-CI записывается следующим образом:

image: python:3.6

before_script:
  # which ssh-agent 用于寻找ssh-agent是否存在，
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  # 启动ssh-agent
  - eval $(ssh-agent -s)
  # 设置环境变量SSH_PRIVATE_KEY，并将私钥添加到agent store
  - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
  # 修改权限
  - mkdir -p ~/.ssh && chmod 700 ~/.ssh
  # 跳过SSH询问
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

# 上文添加的是项目私钥，如果SSH连接成功则能够下拉项目代码
ssh-test:
  script:
    - git clone git@git.xx
    # 远程到其他机器并执行命令
    - ssh root@172.17.0.3 "cd /root && mkdir your_dir"
    # 如果使用非默认端口
    - ssh -p 5555 root@172.17.0.3 "cd /root && mkdir your_dir"

link:
docs.git lab.com/ohoh/this/anytime_can…
Зак говорит Leo.GitHub.IO/2017/04/14/…

stages

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

Ключевое слово stage имеет два свойства:
1. Если имена стадий, соответствующие двум задачам, совпадают, эти две задачи будут выполняться параллельно.
2. Задача, связанная со следующим этапом, будет ожидать успешного выполнения предыдущего этапа, прежде чем продолжить выполнение, и не будет выполняться в случае сбоя.

image: python:3.6

stages:
  - build
  - test
  - deploy
# build-job1和build-job2会并行执行
build-job1:
  stage: build
  script:
    - echo $PWD

build-job2:
  stage: build
  script:
    - echo $PWD

# 这个任务会在build-job1和build-job2执行成功后再运行
test-job:
  stage: test
  script:
    - echo $PWD

# 注意定义的stage都需要用到
deploy-job:
  stage: deploy
  script:
    - echo $PWD

Схема эффекта выглядит следующим образом:

Примечание. Если вы хотите управлять этапом, который будет выполняться в начале или в конце, вы можете использовать.preи.postключевые слова

only / except

Эти две области, которые заставляют меня любить ненавидеть, нет ни одной.

Для лучшей иллюстрации нам также необходимо ввестиPipelinesКонцепция Pipelines заключается в том, что мы видим строки записей в пользовательском интерфейсе Gitlab:

Как показано на рисунке выше, всего существует три конвейера.Внутри каждого конвейера находится выполнение определенных нами задач.Это так просто.

Как упоминалось ранее, порядком выполнения задач можно управлять с помощью ключевого слова stages, а порядком выполнения задач можно управлять с помощью ключевого слова stages.only/exceptКлючевое слово управляет условием срабатывания задачи.

Ключевое слово only/except содержит несколько подключевых слов (или вы можете понимать это как стратегию), которые запускают выполнение Pipelines при соблюдении определенной стратегии, за исключением наоборот.

Стратегия по умолчанию единственного ключевого слова ['ветки', 'теги'], то есть, если вы отправляете ветвь или тег, это сработает,

Кроме того, ключевые слова only/except делятся на базовые функции и расширенные функции, а также включаются подключевые слова.Рекомендуется внимательно прочитать официальную документацию.

только/кроме (основной):

  • ветки: срабатывает, когда ваши Git Refs соответствуют ветке
  • теги: срабатывает, когда ваши Git Refs соответствуют тегу
  • толкает: когда вы используетеgit pushкурок
  • web: когда вы используете веб-интерфейсRun Pipelineкурок
  • merge_requests: запускается, когда вы создаете или обновляете запрос на слияние.
  • ...

only/except(advanced):

  • refs: обратите внимание на отношения XOR
  • variables
  • changes
  • kubernetes

Вот несколько примеров, надеюсь, это поможет вам

1. Конвейеры будут запускаться только в том случае, если отправленная ветка является главной.

image: python:3.6

# 第一种方式
job1:
  only:
    - master
  script:
    - echo $PWD

# 第二种方式
job2:
  only:
    refs:
      - master
  script:
    - echo $PWD

# 第三种方式
job3:
  only:
    variables:
      - $CI_COMMIT_REF_NAME == "master"
  script:
    - echo $PWD

2. Конвейеры будут запускаться при попадании в тег (обычное представление не будет)

image: python:3.6

# 第一种方式
job1:
  only:
    - tags
  script:
    - echo $PWD
  
# 第二种方式
job2:
  only:
    refs:
      - tags
  script:
    - echo $PWD

3. Конвейеры запускаются, когда отправленная ветка является основной или помеченной

image: python:3.6

# 举这个例子是想说明only关键字之间的关系是”或“关系
job1:
  only:
    - master
    - tags
  script:
    - echo $PWD

4. Когда отправленная ветка является главной, а теги используются для запуска конвейеров.
Я еще не нашел способ, но он должен работатьrulesРеализация ключевого слова

5. При использовании веб-интерфейсаRun PipelinesСрабатывает, когда (лично считаю, что этот метод очень полезен)

image: python:3.6

# 举这个例子是想说明only关键字之间的关系是”或“关系
job1:
  only:
    - web
  script:
    - echo $PWD

ссылка на сайт:
git ссылки:git-triplegate.com/book/this/v2/…
Регулярный матч:stackoverflow.com/questions/5…

tags

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

image: python:3.6

# 举这个例子是想说明only关键字之间的关系是”或“关系
job1:
  only:
    - dev
  tags:
    - machine1
  script:
    - echo $PWD

when

Как упоминалось ранее, ключевое слово этапов может управлять порядком выполнения каждой задачи, и следующий этап будет ждать успешного выполнения предыдущего этапа перед выполнением.Если мы хотим достичь предыдущего этапа и потерпеть неудачу, последний этап все еще может быть выполнен эффект?

В это время может вступить в игру ключевое слово when, которое имеет всего пять значений:

  • on_success: выполняется только тогда, когда все предыдущие этапы выполнены успешно, это значение по умолчанию.
  • on_failure: выполнить после сбоя любого задания на предыдущих этапах.
  • всегда: выполнять независимо от состояния заданий на предыдущих этапах.
  • вручную: выполнить вручную
  • отложено: отложенное выполнение
# 官方示例
stages:
  - build
  - cleanup_build
  - test
  - deploy
  - cleanup

build_job:
  stage: build
  script:
    - make build

# 如果build_job任务失败，则会触发该任务执行
cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure

test_job:
  stage: test
  script:
    - make test

deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual

# 总是执行
cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always

cache

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

Стоит отметить, что кэш не может кэшировать файлы вне рабочего пути. Например, ваш пользователь — yangan, проект — helloworld, а рабочий путь по умолчанию — /build/yangan/helloworld.Если вы хотите кэшировать файл в /root, появится ошибка «файл не найден».

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

image: python:3.6

cache:
  # 注意是相对路径
  paths:
    - cache_dir/


job1:
  script: echo $PWD
  # 针对单个任务
  cache:
    - binaries/

относительный путь:stackoverflow.com/questions/5…

artifacts

Подобно ключевому слову cache, файлы или папки также могут кэшироваться, разница в том, что эти файлы можно загрузить в пользовательском интерфейсе Gitlab и, как правило, использовать для хранения apk, сгенерированного пакетом Android.


image: python:3.6

job1:
  artifacts:
    paths:
      - binaries/
    # 设置过期时间
    expire_in: 1 week

Переменная

В Gitlab-CI есть несколько типов переменных, которые являются предопределенными переменными среды, такими какCI_COMMIT_SHA, CI_COMMIT_MESSAGE; переменные задаются через веб-интерфейс Settings/CI-CD, и.gitlab-ci.ymlопределенная переменная.

Через предопределенные переменные среды мы можем получить имя ветки и отправленное сообщение, чтобы определить, нужно ли выполнять задачу; а переменные, установленные в настройках веб-интерфейса/CI-CD, очень подходят для хранения открытых и закрытых ключей. , пароли учетных записей и другие неудобства общедоступных данных. Потому что только владелец и сопровождающий могут просматривать его.

Следующий рисунок определяетSSH_PRIVATE_KEYдля хранения закрытого ключа:

ссылка на сайт:
ключевое слово переменных:docs.git lab.com/ohoh/this/varia…
Предопределенные переменные Gitlab:docs.git lab.com/test/this/varia…
Переменные среды:docs.git lab.com/test/this/varia…

возникшие проблемы

1.!=Этот символ поддерживается только в версиях 11.11 и выше.

2. Удалить конвейеры через API:
docs.git lab.com/ohoh/API/pipe…
git lab.com/git lab-org/…

Ссылаться на

Что такое CI/CD?

Порекомендуйте некоторые лучшие инструменты CI/CD с открытым исходным кодом

Подробное объяснение конфигурации gitlab-ci (2)

Отладка запущенной задачи

Использование тегов в Git

Категории