r10k: proper merging workflow with git

Question

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 06:46

score 2 · Answer 1 · edited Apr 13 '17 at 12:13

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.

edited Apr 13 '17 at 12:13

Community

1

answered Aug 14 '16 at 20:29

Greg Dubicki

1,191
1
14
30

I will try it and report back. – M. Glatki Aug 15 '16 at 06:46
1

@M.Glatki Did you test this? If so: How are your experiences? – gxx Sep 06 '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: https://github.com/puppetlabs/r10k/blob/master/doc/puppetfile.mkd#control-repo-branch-tracking – M. Glatki Sep 26 '16 at 13:12

score 1 · Accepted Answer · answered Sep 26 '16 at 13:17

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.

r10k: proper merging workflow with git

2 Answers2