r10k 3.5.2

data/CODEOWNERS

@@ -0,0 +1,2 @@
+*        @puppetlabs/puppetserver-maintainers @adrienthebo @dhollinger
+/docker/ @puppetlabs/pupperware

data/CONTRIBUTING.mkd

@@ -0,0 +1,105 @@
+Contributing
+============
+
+## Bug reports and feature requests
+
+Bug reports and feature requests may be filed on the [GitHub issue
+tracker][github-issue-tracker]. When filing a bug report or feature request,
+please spend a moment to look for existing issue reports and update those with
+additional information if possible.
+
+[github-issue-tracker]: https://github.com/puppetlabs/r10k/issues
+
+### Bug reports
+
+When filing a bug report, include as much relevant detailed information as
+possible. Try to include the following:
+
+  * A descriptive summary of the bug
+  * When the bug first occurred
+  * What sort of events may have triggered the bug
+  * The expected behavior
+  * The actual behavior
+  * Steps to reproduce
+
+If if you're seeing errors or crashes you can run R10K with the `-v debug2` to
+greatly increase the log level and `--trace` to print any stack traces that may
+be caught.
+
+Including a reproduction environment with something like Vagrant is tremendously
+helpful and can greatly speed up the time it takes to fix your issue!
+
+### Feature requests
+
+When filing a feature request, include information about how important the
+feature is, how it would generally be used in your environment, and how often
+this feature would be used by other users as well. Please keep in mind that
+each added feature incurs additional maintenance costs, so feature requests
+should strive to solve a frequent pain point for users or generally make r10k a
+more effective tool for a large number of r10k users.
+
+The policy towards feature requests in r10k has been greatly shaped by Brian
+Granger's post on [features and scope in open source software][features-and-scope].
+
+Try to include the following:
+
+  * A descriptive summary of the feature
+  * How you expect to use this feature
+  * How important this feature is for your environment
+  * How useful this feature would be for other users
+  * Any potential caveats this may have or any issues this feature may have
+
+[features-and-scope]: http://brianegranger.com/?p=249 "Features and Scope in Open Source Software"
+
+## Documentation
+
+Contributing fixes and improvements to the core documentation is a great way to
+help improve R10K. Improvements to the FAQ, example code, and so forth can go a
+long way towards making R10K more approachable for new users and existing users
+alike. For more information about the submission process please see the section
+on [code contributions](#code-contributions).
+
+## Code contributions
+
+This documentation is based on the Project Hydra
+[CONTRIBUTING](https://github.com/projecthydra/hydra-head/blob/master/CONTRIBUTING.md)
+guide.
+
+### Making changes
+
+  * Fork the repository on GitHub
+  * Create a topic branch from where you want to base your work.
+    * For new features, base your code off of 'master'.
+    * For critical bugfixes, base your code off of the appropriate maintenance
+      branch series, eg '1.2.x' or '1.3.x'
+    * To create a new topic branch; `git checkout -b fix/master/my_contribution master`
+    * Please avoid working directly on the 'master' branch.
+  * Make commits of logical units.
+    * Your commit message should include a high level description of your work.
+  * Check for unnecessary whitespace with `git diff --check` before committing.
+
+```
+    [code/subsystem] (GH-#) Present tense short summary (80 characters or less)
+
+    More detailed description, if necessary. It should be wrapped to 80
+    characters. Try to be as descriptive as you can, even if you think that
+    the commit content is obvious, it may not be obvious to others. You
+    should add such description also if it's already present in bug tracker,
+    it should not be necessary to visit a webpage to check the history.
+```
+
+  * Make sure you have added the necessary tests for your changes.
+  * Run _all_ the tests to assure nothing else was accidentally broken.
+
+### Submitting changes
+
+  * Push your changes to a topic branch in your fork of the repository.
+  * Submit a pull request from your fork to the project.
+  * Expect to have some further discussion of your submission prior to it being merged.
+
+Please note - code review is an essential part of the code review and submission
+process. In order to keep the code base clean and maintainable questions may be
+asked on implementation decisions and you may be asked to make additional
+changes to the contribution. Remember - feedback is never personal and should be
+given to benefit both the submitter as well as the project receiving the
+contribution.

data/Gemfile

@@ -0,0 +1,15 @@
+source ENV['GEM_SOURCE'] || 'https://rubygems.org'
+gemspec
+
+group :extra do
+  gem 'rugged', '~> 1.0', :platforms => :ruby
+end
+
+group :development do
+  gem 'simplecov', '~> 0.9.1'
+  gem 'ruby-prof', :platforms => :ruby
+end
+
+if File.exists? "#{__FILE__}.local"
+  eval(File.read("#{__FILE__}.local"), binding)
+end

data/LICENSE

@@ -0,0 +1,14 @@
+Copyright 2013, 2014 Adrien Thebo
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+

data/README.mkd

@@ -0,0 +1,118 @@
+r10k
+====
+
+Puppet environment and module deployment
+
+[![Build Status](https://travis-ci.org/puppetlabs/r10k.png?branch=master)](https://travis-ci.org/puppetlabs/r10k)
+
+Description
+-----------
+
+[workflow]: https://puppet.com/docs/puppet/latest/environments_about.html
+
+R10k provides a general purpose toolset for deploying Puppet environments and
+modules. It implements the [Puppetfile](doc/puppetfile.mkd) format and provides a native
+implementation of Puppet [environments][workflow].
+
+Requirements
+------------
+
+R10k supports the Ruby versions `>= 2.3.0`. It's tested on Ruby 2.3.0 up to
+Ruby 2.6.0 + Jruby.
+
+R10k requires additional components, depending on how you plan on managing
+environments and modules.
+
+  - Installing modules from the Puppet Forge requires Puppet 5.0.0+ or later.
+  Puppet 3 or 4 may work, but is generally not recommended.
+  - Git is required for creating environments and modules from Git
+  - SVN is required for creating environments and modules from SVN
+
+Installation
+------------
+
+### Rubygems
+
+For general use, you should install r10k from Ruby gems:
+
+    gem install r10k
+    r10k help
+
+### Puppet Enterprise 3.x
+
+Puppet Enterprise bundles a copy of Ruby, so if you do not want to use the
+system version of Ruby with r10k, you need to use the bundled PE gem command for
+installation:
+
+    /opt/puppet/bin/gem install r10k
+    r10k help
+
+### Puppet 4
+
+Puppet 4 bundles a copy of Ruby, so if you do not want to use the
+system version of Ruby with r10k, you need to use the bundled puppet gem command
+for installation.
+
+    /opt/puppetlabs/puppet/bin/gem install r10k
+    /opt/puppetlabs/puppet/bin/r10k help
+
+### Bundler
+
+If you have more specific needs or plan on modifying r10k you can run it out of
+a git repository using Bundler for dependencies:
+
+    git clone git://github.com/puppetlabs/r10k
+    cd r10k
+    bundle install
+    bundle exec r10k help
+
+Usage
+-----
+
+R10k has two primary roles: installing Puppet modules using a standalone
+Puppetfile, and managing Git and SVN based dynamic environments. For more
+information see the topic specific documentation:
+
+  * [Puppetfile Documentation](doc/puppetfile.mkd)
+   * [Updating your Puppetfile](doc/updating-your-puppetfile.mkd)
+  * [Environment Deployment Documentation](doc/dynamic-environments.mkd)
+  * [Quickstart](doc/dynamic-environments/quickstart.mkd)
+  * [Common Patterns](doc/common-patterns.mkd)
+  * [Workflow Guide](doc/dynamic-environments/workflow-guide.mkd)
+
+For more general questions, see the [FAQ](doc/faq.mkd).
+
+Development
+-----------
+
+### i18n
+
+R10k has now had all user-facing strings in error messages and log messages
+externalized. When adding new error or log messages please follow the
+instructions for [writing translatable code](https://github.com/puppetlabs/gettext-setup-gem#writing-translatable-code).
+
+### l10n
+
+When localizing the strings found in R10k, follow the prescribed
+[translation workflow](https://github.com/puppetlabs/gettext-setup-gem#translation-workflow).
+The workflow describes the rake tasks provided to generate the .po files for
+each locale.
+
+Getting help
+------------
+
+  * IRC: r10k has a dedicated channel, `#r10k`, on Freenode where r10k questions
+  can be directed. Questions about r10k can frequently be asked in `#puppet` as well.
+  * Mailing lists: [puppet-users](https://groups.google.com/forum/#!forum/puppet-users)
+  * Q&A: [Puppet Ask](https://ask.puppetlabs.com/questions/)
+
+Contributors
+------------
+
+Please see the CHANGELOG for a listing of the (very awesome) contributors.
+
+## Maintenance
+
+See [MAINTAINERS](MAINTAINERS) (json file)
+
+Tickets: File at https://tickets.puppet.com/browse/RK

data/Rakefile

@@ -0,0 +1,3 @@
+spec = Gem::Specification.find_by_name 'gettext-setup'
+load "#{spec.gem_dir}/lib/tasks/gettext.rake"
+GettextSetup.initialize(File.absolute_path('locales', File.dirname(__FILE__)))

data/azure-pipelines.yml

@@ -0,0 +1,86 @@
+# Don't run Azure when a branch is updated, only when a PR is updated.
+# Prevents double builds when a PR is made from the main repo and not a fork.
+trigger: none
+pr:
+  autoCancel: true
+  branches:
+    include:
+    - '*'
+
+pool:
+  # self-hosted agent on Windows 10 1903 environment
+  # includes newer Docker engine with LCOW enabled, new build of LCOW image
+  # includes Ruby 2.5, Go 1.10, Node.js 10.10
+  name: Default
+
+variables:
+  NAMESPACE: puppet
+  CONTAINER_NAME: r10k
+  CONTAINER_BUILD_PATH: .
+  LINT_IGNORES:
+  DOCKER_BUILDKIT: 1
+
+workspace:
+  clean: resources
+
+steps:
+- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
+  clean: true  # whether to fetch clean each time
+
+- powershell: |
+    $gemfile = Join-Path -Path (Get-Location) -ChildPath 'docker/Gemfile'
+    $gempath = Join-Path -Path (Get-Location) -ChildPath 'docker/.bundle/gems'
+    bundle config --local gemfile $gemfile
+    bundle config --local path $gempath
+    bundle install --with test
+  displayName: Fetch Dependencies
+  timeoutInMinutes: 1
+  name: fetch_deps
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Write-HostDiagnostics
+  displayName: Diagnostic Host Information
+  timeoutInMinutes: 2
+  name: hostinfo
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Lint-Dockerfile -Name $ENV:CONTAINER_NAME -Ignore ($ENV:LINT_IGNORES -split ' ')
+  displayName: Lint $(CONTAINER_NAME) Dockerfile
+  timeoutInMinutes: 1
+  name: lint_dockerfile
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Build-Container -Name $ENV:CONTAINER_NAME -Namespace $ENV:NAMESPACE -PathOrUri $ENV:CONTAINER_BUILD_PATH
+  displayName: Build $(CONTAINER_NAME) Container
+  timeoutInMinutes: 5
+  name: build_container
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Initialize-TestEnv
+  displayName: Prepare Test Environment
+  name: test_prepare
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Invoke-ContainerTest -Name $ENV:CONTAINER_NAME -Namespace $ENV:NAMESPACE
+  displayName: Test $(CONTAINER_NAME)
+  timeoutInMinutes: 5
+  name: test_container
+
+- task: PublishTestResults@2
+  displayName: Publish $(CONTAINER_NAME) test results
+  inputs:
+    testResultsFormat: 'JUnit'
+    testResultsFiles: 'docker/TEST-*.xml'
+    testRunTitle: $(CONTAINER_NAME) Test Results
+
+- powershell: |
+    . "$(bundle show pupperware)/ci/build.ps1"
+    Clear-BuildState -Name $ENV:CONTAINER_NAME -Namespace $ENV:NAMESPACE
+  displayName: Container Cleanup
+  timeoutInMinutes: 4
+  condition: always()

data/bin/r10k

@@ -0,0 +1,17 @@
+#!/usr/bin/env ruby
+
+require 'r10k/cli'
+require 'colored2'
+
+begin
+  R10K::CLI.command.run(ARGV)
+rescue Interrupt
+  $stderr.puts "r10k: Aborted!".red
+  exit(1)
+rescue SystemExit => e
+  exit(e.status)
+rescue Exception => e
+  $stderr.puts "\nr10k: Runtime error: #{e.inspect}".red
+  $stderr.puts e.backtrace.join("\n").red if ARGV.include? '--trace'
+  exit(1)
+end

data/doc/common-patterns.mkd

@@ -0,0 +1,44 @@
+Common Patterns
+===============
+
+This guide provides common patterns seen in the r10k community. These patterns
+are, of course, simply a guide. Understand why you are or are not using a
+specific pattern before implementing it.
+
+Repository Setup
+----------------
+
+Use a [Control Repo](https://docs.puppet.com/pe/latest/cmgmt_control_repo.html)
+to store your `Puppetfile`.
+
+Hiera data should be in the Control repo OR as a separate source in
+`r10k.yaml`. Any `hiera.yaml` in the Control repo will be ignored on a per
+environment basis, locating it at `/etc/puppetlabs/puppet/hiera.yaml` is prefered.
+
+Each puppet module should be contained in its own independent forge module or
+repository.
+
+Editing modules
+---------------
+
+All environment content is checked out into `$environmentpath/modules` on the
+node r10k is run on, either your puppet master or each masterless node. Edits
+made directly to these files will be lost on the next deploy. It is best
+practice not to edit code on the production system in the production paths.
+
+You may clone upstream repositories in a regular user's directory, on the master
+or on another machine. Create a new feature branch locally, make all required
+edits, and push the new branch upstream when ready for testing. R10k will
+deploy changes from the upstream repositories, eliminating the need for manual
+updates of the `$environmentpath` contents.
+
+Automated deploys
+-----------------
+
+To reduce manual intervention, use a post-receive hook on your control and
+module repos to initiate an r10k deploy. You can develop your own or use a
+publicly available hook. These include:
+
+* [Reaktor](https://github.com/pzim/reaktor)
+* [zack/r10k's Webhooks](https://forge.puppetlabs.com/zack/r10k#webhook-support)
+(Puppet Enterprise only)

data/doc/dynamic-environments.mkd

@@ -0,0 +1,31 @@
+Dynamic Environments
+====================
+
+Dynamic environment deployment is the core functionality of r10k.
+
+Table of contents
+-----------------
+
+  * [Introduction](dynamic-environments/introduction.mkd): A brief description of
+    what dynamic environments are and how they work.
+  * [Quickstart](dynamic-environments/quickstart.mkd): Getting started with the
+    essentials of dynamic environments and r10k.
+  * [Configuration](dynamic-environments/configuration.mkd) A reference of dynamic
+    environment configuration options and how they're used
+  * [Git environments](dynamic-environments/git-environments.mkd) How r10k
+    implements dynamic environments using git
+  * [Master Configuration](dynamic-environments/master-configuration.mkd) How to
+    configure your Puppet masters to use dynamic environments
+  * [Workflow Guide](dynamic-environments/workflow-guide.mkd) A general-purpose
+    workflow guide for using r10k.
+  * [Usage](dynamic-environments/usage.mkd) A reference of r10k commands and how
+    they're used.
+
+- - -
+
+Community guides
+----------------
+
+  * [Building a Functional Puppet Workflow Part 3: Dynamic Environments with R10k](http://garylarizza.com/blog/2014/02/18/puppet-workflow-part-3/)
+  * [Puppet Infrastructure with r10k](http://terrarum.net/blog/puppet-infrastructure-with-r10k.html)
+  * [Puppet for vSphere Admins](http://rnelson0.com/puppet-for-vsphere-admins/) Installing and using r10k in a vSphere environment