Используйте 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, что должны использовать ваши агенты?

• Как выглядит остальная часть вашей инфраструктуры? Сколько агентов на месте? Как вы тестируете свой код, т. Е. Как сказать {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:

  # 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 филиал вашего контрольного репо.

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

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

    puppet agent -t --environment ${FEATURE_BRANCH}
    

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