Блог

Главная - Вопросы по программированию - Gitlab и размещение скриптов со скрытыми ключами во включаемых файлах

Gitlab и размещение скриптов со скрытыми ключами во включаемых файлах

#gitlab #yaml #aliases

#gitlab #yaml #Псевдонимы

Вопрос:

У меня есть то, что составляет несколько разных скриптов, которые я хочу запускать на различных этапах в нескольких проектах. В настоящее время они имеют вид:

 .hidden_key:  amp;hidden_key |
  do_something
  do_something_else

real_job:
  script:
    - *hidden_key

Эффективно .hidden_key это функция, которую я использую во всем .gitlab-ci.yml файле и в нескольких проектах таким образом. Но, похоже, я не могу заставить включить работу, когда я перемещаюсь .hidden_key в файл и включаю его следующим образом:

 include:
   - remote: https://gitlab/project/master/raw/hidden_key.yml

real_job:
  script:
    - *hidden_key

Когда я это делаю, gitlab жалуется на:

 Error: Unknown alias: hidden_key

Я что-то делаю неправильно, или это фактическое ограничение включений (и, следовательно, не поддерживается)?

Какие существуют альтернативы для очистки моего .gitlab-ci.yml файла?

Ответ №1:

Они добавили !reference теги

По сути, именно так вы можете выполнить ссылку на псевдоним

     include:
       - remote: https://gitlab/project/master/raw/hidden_key.yml
    
    real_job:
      script:
        - !reference [.hidden_key]

Ответ №2:

Это почти наверняка ограничение includes (которое было бы намного лучше реализовать явно с помощью тега).

Стандартная загрузка YAML состоит из этапа синтаксического анализа, компоновки и построения. Псевдонимы разрешаются на этапе создания, и привязки, например, не переносятся на следующий документ в многодокументном файле YAML.

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

Вам повезет больше, если вы используете какую-нибудь систему шаблонов jinja2, для которой вы, конечно, можете заполнить переменную, которая будет заменена из вашего файла YAML, также обычными этапами.

Комментарии:

1. вы предлагаете мне использовать шаблоны jinja2 в файле .gitlab-ci.yml? Или что я должен каким-то образом создать этот файл, используя шаблоны jinja2 с помощью скрипта? Если последнее, может ли gitlab сделать это автоматически с помощью триггеров фиксации или чего-то еще? Если да, то указатели на документы, объясняющие это, были бы весьма кстати! Спасибо за ваш ответ, кстати, очень признателен!

2. Я понятия не имею, можно ли это сделать в gitlab. Я сделал нечто похожее на docker-compose (предоставляя недоступную функциональность), внедрив новую команду, которая генерирует файл YAML, который ожидает docker-compose, а затем вызывает docker-compose. И для поддержки формата файла документации на основе YAML на readthedocs.org запустив предварительный процессор в документах, на их серверной части. Последнее возможно, поскольку они позволяют запускать код python в изолированной среде, gitlab нужно было бы предоставить что-то подобное, но я не знаю, делает ли это.

Ответ №3:

Вы пробовали использовать extends ? Документация

Пример:

 include:
   - remote: https://gitlab/project/master/raw/hidden_key.yml

real_job:
  extends: .hidden_key