Расширение переменной свойства ветвления триггера предотвращает создание нисходящего конвейера

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

Действия по воспроизведению

  1. Настройте нисходящий конвейер со свойством trigger, как обычно.
  2. Добавьте свойство branch к свойству триггера. Напишите имя существующей ветки в нижележащем репозитории, например _3 _ / _ 4_, или имя ветки функции.
  3. Запустите конвейер и убедитесь, что последующий конвейер успешно создан.
  4. Теперь измените свойство branch, чтобы вместо него использовалась переменная, например branch: $CI_TARGET_BRANCH.
  5. Вручную запустите конвейер CI с этим, задав переменную через графический интерфейс GitLab.
  6. Задание немедленно завершится ошибкой по причине: нисходящий трубопровод не может быть создан.

Пример кода

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

Это работает, создавая нисходящий конвейер, как обычно. Но имя ветки жестко запрограммировано:

stages:
  - deploy

deploy:
  variables:
    environment: dev
  stage: deploy
  trigger:
    project: group/project
    branch: foo
    strategy: depend

Это не работает; хотя TARGET_BRANCH установлен успешно, задание не выполняется, потому что нисходящий конвейер не может быть создан:

stages:
  - removeme
  - deploy

before_script:

  - if [ -z "$TARGET_BRANCH" ]; then TARGET_BRANCH="main"; fi
  - echo $TARGET_BRANCH

test_variable:
  stage: removeme
  script:
    - echo $TARGET_BRANCH

deploy:
  variables:
    environment: dev
  stage: deploy
  trigger:
    project: group/project
    branch: $TARGET_BRANCH
    strategy: depend

Если вы знаете, что я делаю неправильно, или у вас есть что-то, что работает с расширением переменных свойства ветки, поделитесь этим (вместе со своей версией GitLab). Альтернативные решения также приветствуются, но кажется, что это должно сработать.

Версия GitLab, в которой возникает ошибка

Самостоятельная версия GitLab Community Edition 12.10.7

Каково текущее поведение ошибки?

Работа всегда терпит неудачу по причине: нисходящий трубопровод не может быть создан.

Какое поведение ожидается правильным?

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

Подробнее

  • Возможность использовать расширение переменной в свойстве ветви триггера была добавлена ​​в v12.4, а явно упоминается в документации.
  • I searched for other .gitlab-ci.yml / GitLab config files. Every single one that attempted to use variable expansion in the branch property had it commented out, saying it was bugged for an unknown reason (example.
    • I haven't been able to find a repository in which someone claimed to have a working variable expansion for the branch property of the trigger property.
  • К сожалению, альтернативными решениями являются либо (а) жесткое кодирование каждого имени дочерней ветки в конфигурацию GitLab CI восходящего проекта, либо (б) невозможность протестировать изменения в нижней части конфигурации GitLab CI без предварительной фиксации их в _12 _ / _ 13_, или вам необходимо использовать _14 _ / _ 15_.

TL; DR: как использовать значение переменной для свойства ветвления задания моста? Мое текущее решение позволяет избежать сбоя задания и не создавать конвейер ниже по потоку.


gitlab continuous-integration gitlab-ci continuous-delivery
person Erik Humphrey    schedule 17.06.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

это «работает как задумано», и в следующих выпусках gitlab будет улучшаться.

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

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

Вызовы API дают вам полный контроль

curl -X POST \
          -s \
          -F token=${CI_JOB_TOKEN} \
          -F "ref=${REF_NAME}" \
          -F "variables[STAGE]=${STAGE}" \
          "${CI_SERVER_URL}/api/v4/projects/${CI_PROJECT_ID}/trigger/pipeline"

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

Более того, CI_JOB_TOKEN не может использоваться для получения статуса последующего задания, поэтому вы получите еще один токен для этого.

- |

DOWNSTREAM_RESULTS=$( curl --silent  -X POST \
      -F token=${CI_JOB_TOKEN} \
      -F "ref=${DOWNSTREAM_PROJECT_REF}" \
      -F "variables[STAGE]=${STAGE}" \
      -F "variables[SLS_PACKAGE_PATH]=.serverless-${STAGE}" \
      -F "variables[INVOKE_SLS_TESTS]=false" \
      -F "variables[UPSTREAM_PROJECT_REF]=${CI_COMMIT_REF_NAME}" \
      -F "variables[INSTALL_SLS_PLUGINS]=${INSTALL_SLS_PLUGINS}" \
      -F "variables[PROJECT_ID]=${CI_PROJECT_ID}" \
      -F "variables[PROJECT_JOB_NAME]=${PROJECT_JOB_NAME}" \
      -F "variables[PROJECT_JOB_ID]=${PROJECT_JOB_ID}" \
      "${CI_SERVER_URL}/api/v4/projects/${DOWNSTREAM_PROJECT_ID}/trigger/pipeline" )
      echo ${DOWNSTREAM_RESULTS} | jq .
      DOWNSTREAM_PIPELINE_ID=$( echo ${DOWNSTREAM_RESULTS} | jq -r .id )
      echo "Monitoring Downstream pipeline ${DOWNSTREAM_PIPELINE_ID} status..."
      DOWNSTREAM_STATUS='running'
      COUNT=0
      PIPELINE_API_URL="${CI_SERVER_URL}/api/v4/projects/${DOWNSTREAM_PROJECT_ID}/pipelines/${DOWNSTREAM_PIPELINE_ID}"
      echo "Pipeline api endpoint => ${PIPELINE_API_URL}"
      while [ ${DOWNSTREAM_STATUS} == "running" ]
      do
         if [ $COUNT -eq 0  ]
        then
          echo "Starting loop"
        fi
        if [ ${COUNT} -ge 350 ]
        then
          echo 'TIMEOUT!'
          DOWNSTREAM_STATUS="TIMEOUT"
          break
        elif [ $(( ${COUNT}  % 60 )) -eq 0 ]
        then
          echo "Downstream pipeline status => ${DOWNSTREAM_STATUS}"
          echo "Count => ${COUNT}"
          sleep 10 
        else 
          sleep 10 
        fi
        DOWNSTREAM_CALL=$( curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" ${PIPELINE_API_URL} )
        if [ $COUNT -eq 0  ]
        then
          echo ${DOWNSTREAM_CALL} | jq .
        fi
        DOWNSTREAM_STATUS=$( echo ${DOWNSTREAM_CALL} | jq -r .status )
        COUNT=$(( ${COUNT} + 1 ))

      done
      #pipeline status is running, failed, success, manual
      echo "PIPELINE STATUS => ${DOWNSTREAM_STATUS}"
      if [ ${DOWNSTREAM_STATUS} != "success" ]
      then
        exit 2
      fi
person BJHop    schedule 23.06.2020