Jenkins — Примеры

Пример 1 — Задача, которая существует только в интерфейсе

Задача сборки была настроена вручную в веб-интерфейсе: три шага оболочки и заархивированный артефакт. Когда коллега просит изменить команду тестов, никто не может сказать, где живёт определение задачи. Перенесите задачу в репозиторий файлом конвейера, оставив серверу только учётные данные и конфигурацию агентов.

job "api-build"
  agent: any
  steps:
    1. выгрузить репозиторий
    2. запустить ./run-tests.sh
    3. заархивировать dist/*.tgz

Решение

// Jenkinsfile, в репозитории рядом с кодом, который он собирает
pipeline {
  agent { label 'build' }
  stages {
    stage('Сборка и тесты') {
      steps {
        sh './run-tests.sh'
        archiveArtifacts artifacts: 'dist/*.tgz'
      }
    }
  }
}

Теперь определение живёт там, где его рецензируют, версионируют и восстанавливают вместе с кодом, поэтому удаление задачи из интерфейса и её пересоздание из этого файла дают то же поведение. Шаги не изменились; конвейер просто стал диффом, который может прочитать человек. Обычная ошибка — перенести шаги в файл, но оставить агента и триггер выбранными в интерфейсе: это возвращает половину определения обратно в базу данных сервера.

Пример 2 — Развёртывание, которое идёт где угодно, где шла сборка

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

pipeline {
  agent any
  stages {
    stage('Сборка')  { steps { sh './build.sh' } }
    stage('Развёртывание') { steps { sh './deploy.sh' } }
  }
}

агенты: два в облаке, один внутри внутренней сети

Решение

pipeline {
  agent { label 'build' }        // облачные агенты, без доступа во внутреннюю сеть
  stages {
    stage('Сборка') { steps { sh './build.sh' } }
    stage('Развёртывание') {
      agent { label 'internal' } // единственный агент, достающий до хранилища
      steps { sh './deploy.sh' }
    }
  }
}

build    держит только учётные данные сборки
internal держит учётные данные развёртывания, и только эта стадия может ими пользоваться

Сетевое положение агента решает, до чего достанут его сборки, — это и есть смысл своего сервера и повод привязать агента к коду, который он собирает. Закрепление стадии развёртывания, а не всего конвейера, держит учётные данные развёртывания подальше от облачных агентов. Обычная ошибка — agent any, что тихо делит каждые учётные данные с каждой задачей на сервере.