Adding whitelist and blacklist for branch names

[lazyfrosch]

While designing a big Puppet environment and having multiple teams work together on the same Puppet infrastructure, we noticed that r10k might need some kind of white and blacklisting.

Our idea on how to use r10k and branches:

:sources:
  :team1:
    remote: 'git.company.com:team1/puppet-environment.git'
    basedir: '/etc/puppet/environments'
  :team2:
    remote: 'git.company.com:team2/puppet-environment.git'
    basedir: '/etc/puppet/environments'

Each team would have its own namespace and might be using a common environment for baselining and OS stuff.

Resulting in a environment list like:

• team1_prod
• team1_qa
• team1_dev
• team2_prod
• team2_qa
• team2_dev

My idea was to build something like the following to avoid overlapping and conflicts between the team repositories:

:sources:
  :common:
    remote: 'git.company.com:os-team/puppet-environment.git'
    basedir: '/etc/puppet/environments'
    blacklist: 'feature/.*'
  :team1:
    remote: 'git.company.com:team1/puppet-environment.git'
    basedir: '/etc/puppet/environments'
    whitelist: 'team1_\w+'
    blacklist: 'feature/.*'
  :team2:
    remote: 'git.company.com:team2/puppet-environment.git'
    basedir: '/etc/puppet/environments'
    whitelist: 'team2_\w+'
    blacklist: 'feature/.*'

Any branches that are on the blacklist, or not on the whitelist are simply ignored.

[lazyfrosch]

I just noticed that #129 takes care about the same problem, and might be a better approach.

[lazyfrosch]

My problem is fixed with using "prefix" and id might have to have a "branches to use list" like in #129

Feel free to close this ticket.

[wcooley]

May I suggest that this enhancement request remain open? I have a use-cases where I think this would be the most obvious solution (and can imagine other use-cases).

I am just starting to work with r10k, so I am experimenting with it using Vagrant on my laptop. I've started a control repo and have a "production" branch with a Puppetfile that points to our internal git repo host for modules; now I leave the office and want to work off-line, so I create offline branches and adjust the control repo in r10k.yaml and Puppetfile to point local clones. If I run r10k again, it will still try to contact my unreachable "production" remote and barf.

At this point, there are a few options, none of which are ideal:

• Delete the local "production" branch and any branches other than my offline branches from my local clone.
• Checkout the "production" and other branches and update all of their _Puppetfile_s to point to the local clone. I also should break the remote-tracking for these branches, lest I accidentally push them when back on-line.
• Only run r10k explicitly listing my offline environments (which is less than ideal if want I want to develop & test is mass-deployment with r10k itself).
• Use ~puppet/.ssh/config to point the remote host to localhost; that's especially hairy if the remote SSH remote requires a non-standard port (as Atlassian Stash does). (I tried this and it's just too fiddly.)

Whitelisting my off-line branches seems like a more obvious solution than any of these. I could also imagine having multiple Puppet masters and not wanting all branches to be realized on all of them, perhaps to further minimize the potential damage a bad module (with, say, a defective Ruby plugin) could do.

("Offline" might not be the best term here, because regardless of any of these solutions, GitHub and Forge modules will still cause r10k to barf. But these are generally easier to reach than our internal Git host, which requires bringing up a VPN and ensuring the VMs are correctly routing through the VPN and resolving DNS through the VPN, etc.)

[adrienthebo]

Whitelisting/blacklisting is still on the roadmap because it dovetails nicely with a lot of other features, so I'm planning on leaving this open and implementing it when possible.

[hybby]

Hello, is this feature still under development? It would be supremely useful for my use-case :)

[github-actions[bot]]

This issue has been marked stale because it has had no activity for 60 days. The Puppet Team is actively prioritizing existing bugs and new features, if this issue is still important to you please comment and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.