Как переопределить переменные среды в jenkins_job_builder на уровне работы?

Question

Я пытаюсь найти способ наследования / переопределения переменных среды в заданиях jenkins, определенных с помощью jenkins-job-builder (jjb).

Вот один шаблон, который не работает:

#!/usr/bin/env jenkins-jobs test
- defaults: &sample_defaults
    name: sample_defaults

- job-template:
    name: 'sample-{product_version}'
    project-type: pipeline
    dsl: ''
    parameters:
      - string:
          name: FOO
          default: some-foo-value-defined-at-template-level
      - string:
          name: BAR
          default: me-bar

- project:
    defaults: sample_defaults
    name: sample-{product_version}
    parameters:
      - string:
          name: FOO
          value: value-defined-at-project-level
    jobs:
      - 'sample-{product_version}':
          product_version:
              - '1.0':
                   parameters:
                     - string:
                         name: FOO
                         value: value-defined-at-job-level-1
              - '2.0':
                # this job should have:
                # FOO=value-defined-at-project-level
                # BAR=me-bar

Обратите внимание, что ключом является возможность переопределения этих параметров на уровне задания или проекта вместо шаблона.

Требования * быть в состоянии добавить столько переменных окружения, как это, без необходимости добавлять одну переменную JJB для каждой из них * пользователь не должен быть вынужден определять их на уровне шаблона или задания * эти переменные должны быть представлены как переменные окружения во время выполнения для конвейеров и вольных работ. * синтаксис гибкий, но словарный подход будет высоко оценен, например:

vars:
  FOO: xxx
  BAR: yyy

Answer 1

Первое, что нужно понять, это то, как JJB определяет приоритеты, откуда он будет извлекать переменные.

1. определение раздела рабочей группы
2. определение раздела проекта
3. определение переменной шаблона задания
4. определение по умолчанию

(Это не полный список, но он охватывает функции, которые я использую)

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

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

Объявление переменных по умолчанию

При этом существует два способа, которыми JJB позволяет нам определять значения по умолчанию для параметра в шаблоне задания:

Метод 1) Использование {var | default}

В этом методе мы можем определить значение по умолчанию вместе с определением переменной. Например:

- job-template:
    name: '{project-name}-verify'
    parameters:
      - string:
          name: BRANCH
          default: {branch|master}

Однако, где этот метод не работает, если вам нужно использовать одну и ту же переменную JJB в нескольких местах, так как у вас будет несколько мест для определения значения по умолчанию для шаблона. Например:

- job-template:
    name: '{project-name}-verify'
    parameters:
      - string:
          name: BRANCH
          default: {branch|master}

    scm:
      - git:
         refspec: 'refs/heads/{branch|master}'

Как вы можете видеть, у нас теперь есть 2 места, где мы объявляем {branch | master} не идеальным.

Метод 2) Определение значения переменной по умолчанию в самом шаблоне задания

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

- job-template:
    name: '{project-name}-verify'

    #####################
    # Variable Defaults #
    #####################

    branch: master

    #####################
    # Job Configuration #
    #####################

    parameters:
      - string:
          name: BRANCH
          default: {branch}

    scm:
      - git:
         refspec: 'refs/heads/{branch}'

В этом случае все еще есть 2 ветви определений для шаблона задания. Однако мы также предоставляем значение по умолчанию для переменной {branch} в верхней части файла. Только раз. Это будет значение, которое будет выполнять задание, если оно не передано проектом с использованием шаблона.

Переопределение переменных шаблонов работ

Когда проект хочет использовать шаблон задания, я предпочитаю использовать один из 2 методов в зависимости от ситуации.

- project:
    name: foo
    jobs:
      - '{project-name}-merge'
      - '{project-name}-verify'

    branch: master

Это стандартный способ, который использует большинство людей, и он устанавливает branch: master для каждого шаблона работы в списке. Однако иногда вы можете указать альтернативное значение только для 1 задания в списке. В этом случае более конкретное объявление имеет приоритет.

- project:
    name: foo
    jobs:
      - '{project-name}-merge':
          branch: production
      - '{project-name}-verify'

    branch: master

В этом случае задание проверки получит значение «master», но вместо этого задание на слияние получит значение ветви «production».