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

Question

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

Шаги для воспроизведения

1. Настройте нисходящий конвейер со свойством trigger, как обычно.
2. Добавьте свойство branch к свойству триггера. Напишите имя существующей ветки в репозитории ниже по потоку, например master / main или имя ветки функции.
3. Запустите конвейер и убедитесь, что конвейер вниз по течению успешно создан.
4. Теперь измените свойство branch, чтобы вместо этого использовалась переменная, например branch: $CI_TARGET_BRANCH.
5. Вручную запустите конвейер CI с этим, задав переменную через GitLab GUI.
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 поискал другие файлы конфигурации .gitlab-ci.yml / GitLab. Каждый, кто пытался использовать расширение переменной в свойстве ветки, закомментировал это, сказав, что это было ошибкой по неизвестной причине ( пример .
  • Я не смог найти репозиторий, в котором кто-то утверждал, что у него есть расширение рабочей переменной для свойства branch свойства триггера.
• К сожалению, альтернативные решения либо (а) жестко кодируют каждое имя дочерней ветви в конфигурация GitLab CI восходящего проекта или (б) невозможность протестировать изменения в нисходящей конфигурации GitLab CI без предварительной фиксации их в master / main или необходимости использовать only / except.

---

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

Answer 1

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

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

Я использую прямые вызовы 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"

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

Более того, 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