4

I am currently running Puppet with in masterless mode. I am using r10k for module and environment deployment.

Simplified version: The r10k control repository has two branches: testing and production. Changes in production will be automatically distributed to production servers. Changes in testing to some staging servers.

Now, if I am changing things in testing, I sometimes have to change the r10k control repository, too. A common example would be the Puppetfile, which currently looks like this in production:

forge 'forge.puppetlabs.com'

# Forge modules
mod 'puppetlabs/stdlib'
mod 'puppetlabs/concat'
mod 'saz/ssh'

# Custom modules
mod 'ownmodule1',
        :git => 'https://git.example.org/configuration/ownmodule1.git',
        :ref => 'production'
mod 'ownmodule2',
        :git => 'https://git.example.org/configuration/ownmodule2.git',
        :ref => 'production'

The configuration for the Custom modules might look like this on the testing branch:

mod 'ownmodule1',
        :git => 'https://git.example.org/configuration/ownmodule1.git',
        :ref => 'testing'
mod 'ownmodule2',
        :git => 'https://git.example.org/configuration/ownmodule2.git',
        :ref => 'testing'

Now, a commit in testing might look like this:

+mod 'ownmodule3,
+        :git => 'https://git.example.org/configuration/ownmodule3.git',
+        :ref => 'testing'

If I merge this to production, and are not careful, ownmodule3 will be added to production with the testing branch, which could be fatal. This also prevents automated merging when all tests are successful.

How can I modify my repositories or workflow to prevent the accidental merging of branch specific changes?

  • Do you actually currently merge your testing branch of r10k repository into production? What's your idea to do the automated merging? I am asking because it seems to me that it's not possible to automate it in your setup, at first glance at least. – Greg Dubicki Aug 14 '16 at 20:05
  • No, no actually. But at some point merging from some branch to production is going to happen, and the commits might origin from testing. – M. Glatki Aug 15 '16 at 6:46
2

Replacing hard-coded environment names used as refs in your Puppetfile with a variable substituted with current environment name would help make your Puppetfile mergable between branches.

Pseudo code:

mod 'ownmodule1',
  :git => 'https://git.example.org/configuration/ownmodule1.git',
  :ref => ${environment}

For actual code see this answer, but I don't guarantee that it will work in your setup, it's a bit hacky.

But of course to make your environments deploy properly after this change, you would have to create production branch in your modules along with testing and init them both with some minimal, no-op but compiling code for new modules.

PS If this answer is helpful and you decide to upvote it then please upvote the linked answer too.

  • I will try it and report back. – M. Glatki Aug 15 '16 at 6:46
  • 1
    @M.Glatki Did you test this? If so: How are your experiences? – gf_ Sep 6 '16 at 15:26
  • I have found that using the new Control Repo Branch Tracking feature is more reliable, and less prone to errors and regressions: github.com/puppetlabs/r10k/blob/master/doc/… – M. Glatki Sep 26 '16 at 13:12
1

Since r10k 2.4.0, it is possible to have the puppet modules match the branch in the control repository. On the branch testing, the Puppetfile from my question might look like this:

mod 'ownmodule1',
  :git => 'https://git.example.org/configuration/ownmodule1.git',
  :ref => :control_branch

This would result in the branch testing of the module ownmodule to be used in with r10k deploy. This is quite reliable. With :default_branch you can specify a fallback branch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.