Используйте r10k с отдельными репозиториями модулей

По вашему вопросу и комментариям:

Моя проблема заключается в том, что - несмотря на этот вывод - изменения, помещенные в репозиторий модуля, не отражаются в файлах ниже /etc/puppetlabs/code/environments,

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

Если вы хотите отслеживать branch, используйте что-то вроде:

mod 'mymodule',
  :git => 'file:///srv/git/mymodule.git',
  :ref => 'master'

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

Честно говоря, я не уверен, как выглядит ваш рабочий процесс:

• У вас есть контрольное репо с двумя ветками, master а также testing, master является стабильным рабочим кодом, пока вы используете testing для развития?

• Вы нажимаете новый код на testingи как только он достигнет состояния, в котором вам удобно, вы объединяетесь testing в master?

• После этого вы хотите пометить текущее состояние в master как stableкакие ваши агенты должны использовать?

• Как выглядит остальная часть вашей инфраструктуры? Сколько агентов на месте? Как вы тестируете свой код, т.е. как вы говорите {одному, всем} (?) Агентам: "Пожалуйста, используйте этот код, выходящий из этой среды"?

• Выполните следующие действия: если вы используете код master а также testingоткуда ваши агенты знают, какую среду использовать?

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

• В любом случае, удачи! puppet а также r10kособенно в сочетании с git-хуками, это отличная настройка! Используя это сам, это просто здорово!:)

Дополнительная информация:

• Спасибо за разработку вашего рабочего процесса.

• Если вы еще не настолько универсальны с git, и особенно если вы делаете много ветвлений и слияний и боитесь конфликтов слияний, обязательно прочитайте о git rebase, который делает

  повторно применить коммиты поверх другого базового наконечника

• Допустим, вы находитесь в следующей ситуации:

  • Вы разветвляетесь master в feature1,
  • Вы делаете некоторую работу в file1:3-6 в feature1,
  • Ты меняешься file1:7-10 прямо в master исправить актуальную ошибку.
  • Вы хотите объединить feature1 Вернуться в master,
  • Обычно в этот момент вы получаете конфликт слияния, потому что один и тот же файл был изменен в обеих ветвях.
  • Если вы делаете git rebase master в то время как на feature1 перед слиянием это "вытянет" последние состояния / коммиты в feature1В этом случае ошибка исправлена.
  • Теперь сделайте слияние, без конфликтов.
• Я бы не стал ограничиваться только одной веткой в ​​репозиториях модулей. Как вы справляетесь с тестированием нового кода внутри? Это не только ваше контрольное репо, которое должно улучшаться со временем.

• Чтобы сделать это удобным, используйте другую функцию r10k:

  # Track control branch and fall-back to master if no matching branch exists
  mod 'mymodule',
    :git => 'file:///srv/git/mymodule.git',
    :branch => :control_branch,
    :default_branch => 'master'
  

• Это позволит вам сделать следующее, например, в ситуации, когда вы хотите разработать новую функцию в вашем модуле:

  • В вашем контрольном репо, филиал master в testing,
  • В вашем модуле репо, филиал master в testing,
  • Без изменения вашего PuppetfileВаш марионеточный агент, который использует testing ветвь вашего контрольного репо теперь также использует testing ветка вашего модуля репо.
  • Развивайся, пока не будешь доволен.
  • В вашем модуле репо, объединить testing в master,
  • Новый код, который вы разработали, теперь будет доступен всем вашим марионеточным агентам, которые используют производственный код, т.е. master ветка вашего контрольного репо.

• Последнее замечание на данный момент: похоже, что вы единственный, кто разрабатывает код, так что, возможно, это не так важно для вас, но просто чтобы вы знали:

  • Если две ветви слишком ограничены, вполне возможно использовать другую среду во время запуска агента Puppet без изменения конфигурации, но с помощью параметра cli:

    puppet agent -t --environment ${FEATURE_BRANCH}
    

• Это все, что я сейчас могу придумать. Надеюсь, что это поможет, опять же, удачи и всего наилучшего!