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

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

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

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

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

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

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

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

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

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

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

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

• Следуйте приведенным выше мерам: Если у вас есть код в 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 :

   # Отслеживайте управляющую ветвь и переходите к мастеру, если нет подходящей ветки  существует
  мод 'mymodule',
    : git => 'file: ///srv/git/mymodule.git',
    : branch =>: control_branch,
    : default_branch => 'мастер'
   

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

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

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

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

     марионеточный агент -t - среда $ {FEATURE_BRANCH}
     

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