CI Gitlab: Переменная этапа, основанная на глобальной переменной, не разрешается при использовании якорей

# #yaml #gitlab-ci

Вопрос:

У меня есть что-то подобное в моем файле .gitlab-ci.yml:

 .docker_build_cmd: amp;docker_build_cmd >-
  docker build -t $DOCKER_IMAGE_TAG -f $DOCKER_FILE .

variables:
  PROJECT_NAME: best-app-ever
  BUILD_VERSION: 4.2.0
  DOCKER_IMAGE_TAG: $DOCKER_PROJECT_NAME:$BUILD_VERSION

build:
  stage: build
  variables:
    GRADLE_CMD: app:build
    DOCKER_PROJECT_NAME: $PROJECT_NAME-service
    DOCKER_FILE: docker/service.dockerfile
  script:
    - echo $DOCKER_PROJECT_NAME
    - echo $DOCKER_IMAGE_TAG 
    - *docker_build_cmd
 

но раннер говорит:

 $ echo $DOCKER_PROJECT_NAME
best-app-ever
$ echo $DOCKER_IMAGE_TAG
$PROJECT_NAME-service:4.2.0
$ docker build -t $DOCKER_IMAGE_TAG -f $DOCKER_FILE .
invalid argument "$PROJECT_NAME-service:4.2.0" for "-t, --tag" flag: invalid reference format: repository name must be lowercase
 

Кто-нибудь понимает, почему это происходит?
Как Gitlab обрабатывает файл .yml?
И если есть способ заставить это работать так, как я задумал, я действительно хочу знать.

Версия GitLab SaaS-14.3.0-ee.

UPD. После некоторого поиска в Google кажется, что должен быть включен флаг функции «variable_inside_variable». Сделаем это завтра и посмотрим, что изменится.

Ответ №1:

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