RE: #53
This seems to bug purging if multiple sources share the same basedir directory and one has disabled prefixing, seems the non-prefixed source remains and the prefixed one gets deleted:

:cachedir: '/var/cache/r10k'
:sources:
  :hieradata: 
    remote: '[email protected]'
    basedir: '/etc/puppet/environments'
    prefix: true
  :modules: 
    remote: '[email protected]'
    basedir: '/etc/puppet/environments'
    prefix: false

:purgedirs:
  - '/etc/puppet/environments'

# Results in:
[R10K::Task::Deployment::PurgeEnvironments - INFO] Purging stale environments from /etc/puppet/environments
[R10K::Task::Deployment::PurgeEnvironments - DEBUG] Stale modules in /etc/puppet/environments: hieradata_dev, hieradata_prod, hieradata_master
[R10K::Task::Deployment::PurgeEnvironments - DEBUG] No stale environments in /etc/puppet/environments
# Leaving:
$ ls /etc/puppet/environments/
dev  master  prod

I only bring this up because I had trouble getting a modulepath with a prefix working like:
[master] modulepath = /etc/puppet/environments/modules_$environment/modules

(running latest master version through bundle)

~/r10k/lib/r10k$ git log | head -1
commit 68b8f0ecbce44f4c99c740b8765e5e48306249b4
~/r10k/lib/r10k$ git branch
* master

r10k deploy [environment|module] only deploys environment, but does not checkout the modules into /etc/puppetlabs/puppet/environments/master/modules. Only the Puppetfile and the other contents of the r10k-shared branch are checked out, but no action is run on the Puppetfile.

If I cd to the "/etc/puppetlabs/puppet/environments/master/" and run "r10k puppetfile install" then it will install the modules.

r10k version from git: b98b173

Use cases TBD

It would be great if r10k could take a parallel job parameter to speed up checkout of modules.

As far as I understand the Puppetfile format allows specifying Forge modules without a version number. It seems r10k doesn't support that:

[R10K::Action::Environment::Deploy - INFO] Deploying environment testing

Runtime error: #<RuntimeError: Module puppetlabs/apt with args [] doesn't have an implementation. (Are you using the right arguments?)>

The Puppetfile in question:

forge "http://forge.puppetlabs.com"

mod "puppetlabs/apt"
...

Adding a version specification makes it work again:

forge "http://forge.puppetlabs.com"

mod "puppetlabs/apt", "1.1.0"

Using r10k version from git: b98b173

root@master:~/r10k-shared# r10k  deploy display
[R10K::TaskRunner - ERROR] Task #<R10K::Task::Deployment::Display:0x7fc67a899890> failed while running: private method `gsub' called for nil:NilClass
root@master:~/r10k-shared# 
root@master:~/r10k-shared# r10k  deploy environment
[R10K::TaskRunner - ERROR] Task #<R10K::Task::Deployment::DeployEnvironments:0x7f8fb8f8c830> failed while running: private method `gsub' called for nil:NilClass
[R10K::TaskRunner - ERROR] Task #<R10K::Task::Deployment::PurgeEnvironments:0x7f8fb8f8c7b8> failed while running: private method `gsub' called for nil:NilClass
root@master:~/r10k-shared# r10k  deploy module
[R10K::TaskRunner - ERROR] Task #<R10K::Task::Deployment::DeployModules:0x7f4298d537e8> failed while running: private method `gsub' called for nil:NilClass

The contents of r10k.yaml:

root@master:~/r10k-shared# cat /etc/r10k.yaml
:cachedir: /var/cache/r10k
:sources:
  :master:
    remote:  '[email protected]:larstobi/r10k-shared.git'
    basedir: '/etc/puppetlabs/puppet/environments'
:purgedirs:
  - '/etc/puppetlabs/puppet/environments'

When running r10k synchronize I get this error:

Runtime error: #<ArgumentError: Logger must have a name>
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/logging.rb:12:in `new'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/logging.rb:12:in `logger'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/module/forge.rb:44:in `sync!'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/action/module.rb:27:in `call'
/var/lib/gems/1.8/gems/middleware-0.1.0/lib/middleware/runner.rb:31:in `call'
/var/lib/gems/1.8/gems/middleware-0.1.0/lib/middleware/builder.rb:102:in `call'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/action/environment.rb:38:in `call'
/var/lib/gems/1.8/gems/middleware-0.1.0/lib/middleware/runner.rb:31:in `call'
/var/lib/gems/1.8/gems/middleware-0.1.0/lib/middleware/builder.rb:102:in `call'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/cli/synchronize.rb:37:in `command'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:296:in `call'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:296:in `run_this'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:249:in `run'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:262:in `run'
/var/lib/gems/1.8/gems/r10k-0.0.10/bin/r10k:7
/usr/local/bin/r10k:19:in `load'
/usr/local/bin/r10k:19

It seems that self.class.name in Logger is not set for Forge.

As a work-around I applied a patch to /lib/r10k/logging.rb

  def logger
    unless @logger
      @logger = Log4r::Logger.new(self.class.name || 'COMMON')
      @logger.add R10K::Logging.outputter
    end
    @logger
  end

However the real solution may be to make sure all classes that include Logging have a name, or have some other convention for initializing the Log4r name.

If a module is removed from a Puppetfile it won't be purged. Doing an r10k synchronize should purge all module directories of stale modules.

Given a repo with no Puppetfile, it will warn with the following:

[R10K::Root - WARN] #:/etc/puppet/environments/master does not exist, cannot enumerate modules.

If the directory does exist but the Puppetfile doesn't, then maybe a debug message should be logged but a warning shouldn't be thrown.

This release should add support for updating multiple environments and modules in parallel.

We use about 100 Puppet modules, most of them written by us, some of them from the Forge or directly from Github. Our own modules each live in their own Git repository, as in [email protected]/puppet-tomcat, [email protected]/puppet-chrony and so on. Currently we don't even use environments, the modules are cloned directly into /etc/puppet/modules, either from the Forge, Github or our own Git server. This sucks, obviously.

So my question: is r10k useful for us? We don't have a single Git repo containing all modules (no org-shared-repo as the example r10k.yaml file suggests), so I don't understand if r10k can cope with this kind of setup. Seems like it easily could, but I am not sure how to start deploying it. Any hints?

When a Puppetfile is changed from using a module like say: sdarwin/nrpe to using a totally different module with the same module name like: example42/nrpe this is not detected and the module is not purged/installed (as it should be?).

[R10K::Task::Deployment::PurgeEnvironments - DEBUG] No stale environments in /etc/puppet/environments

[R10K::TaskRunner - ERROR] Task #<R10K::Task::Module::Sync:0x7fe5fa059708> failed while running: "puppet module --modulepath '/etc/puppet/environments/master/modules' upgrade --ignore-dependencies example42/nrpe" returned with non-zero exit value #<Process::Status: pid=14992,exited(1)>

Currently the puppetfile subcommand is always installing/updating all the modules specified in the Puppetfile.

To save time and make a more granular approach to installing/updating modules possible, it would be nice if you could specify which module you want to install/update. Something like:

r10k puppetfile install < modulename >

I get an error when I try to run r10k synchronize. It appears that R10K::Root wants
its config hash to be keyed on symbols, but its being given in strings instead.

As you can see, it throws a runtime error even though ref is defined:

Runtime error: #<RuntimeError: Unable to resolve directory name from options {"remote"=>"[email protected]:puppet-modules.git", "ref"=>"production", :basedir=>"/etc/puppet/environments"}>
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/root.rb:71:in `parse_initialize_hash'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/root.rb:26:in `initialize'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:67:in `new'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:67:in `load_all'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:66:in `each'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:66:in `load_all'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:57:in `each_pair'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:57:in `load_all'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment/environment_collection.rb:15:in `initialize'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment.rb:40:in `new'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment.rb:40:in `collection'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/deployment.rb:35:in `environments'
/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/cli/synchronize.rb:18:in `command'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:296:in `call'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:296:in `run_this'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:249:in `run'
/var/lib/gems/1.8/gems/cri-2.3.0/lib/cri/command.rb:262:in `run'
/var/lib/gems/1.8/gems/r10k-0.0.10/bin/r10k:7
/usr/local/bin/r10k:19:in `load'
/usr/local/bin/r10k:19

As a work-around I've tried to make it tolerant of both strings and hashes, but I'm not sure what is the best idiomatic solution to this problem.

Reference Commit: a0a5189

If not, might I request this feature?

The use case is when you are deploying multiple r10k repositories, but only using the modules from one of them and don't need to update all of the modules for all of the branches. Thus, deploying only the per environment branches without cloning any of the modules would be super useful.

If this already exists, apologies, and I am happy to help document.

Git modules should check for the presence of git before module installation is attempted.

Using r10k deploy display -p doesn't accurately reflect the version of the installed modules across Puppet environments.

For Puppetfile entries that specify branches, the module versions are displayed as the branch itself e.g. (master) or (development). While this indicates what the state will be after the next environment sync, it doesn't indicate the last version that was installed.

For example, if I have 3 months worth of commits in my master branch, but haven't deployed them, then seeing (master) in the output of r10k deploy display -p will be misleading.

Either the module version, or the git commit SHA (preferably module version) should be captured, cached, and then displayed when viewing the status of the environments. I propose a new output scheme, and a slightly different command. I don't like having the 'display' command as a sub-command of 'deploy', but I'll follow the scheme as I'm guessing it's attempting to follow the [noun] [verb] approach.

r10k deploy status -p and r10k deploy status -p -y (the latter outputs yaml)

Displays current environments, current module versions, and candidate version to be installed on current branch. Allow for readable output, and yaml output.

example yaml template

[environment]:
  sha: [environment-sha]
  modules:
    - [module]
      version: [current-version] 
      branch: [branch]
      candidate_version: [candidate-version]
    - [module]
      version: [current-version]
      branch: [branch]
      candidate_version: [candidate-version]
[environment]
  sha: [environment-sha]
  modules:
    - [module]
      version: [current-version]
      branch: [branch]
      candidate_version: [candidate-version]      

example yaml output

development:
  sha: abc123
  modules:
    - ntp:
        version: 1.1-dev-4
        branch: development
        candidate_version: 1.1-dev-4
    - apt:
        version: 1.1-dev-1
        branch: development
        candidate_version: 1.1-dev-1
production:
  sha: zyx789
  modules:
    - ntp:
        version: 1.0
        branch: master
        candidate_version: 1.1
    - apt:
        version: 1.0
        branch: master
        candidate_version: 1.1

When the current version does not match the candidate version, hilight that module in the console output to indicate that it will be upgraded on the next sync.

If an instantiated repository is changed to a remote then the cache remote should be updated. Right now the cache remote is set once blindly and never rechecked. This should be improved.

Running r10k --help prints a message that some commands are hidden, "3 hidden commands ommitted; show them with --verbose". Running r10k --help --verbose results in an error, "r10k: option requires an argument -- verbose".

Passing various arguments with the --verbose flag has no affect on displaying the hidden commands.

r10k --help --verbose true
r10k --help --verbose DEBUG

While bootstrapping a new master I've noticed that r10k doesn't fail when the puppet module face is not available (in my case the machine only had 2.7.11).

As discussed in IRC I am opening this issue (a lot later than I'd planned, sorry) for discussion.

When specifying a Forge module in the Puppetfile without specifying a version, for example:

mod "adrien/boolean"

r10k initially installs the module in the latest version available on the Forge, as one would expect. But when the module gets updated on the Forge, r10k does not seem to notice or care and keeps the initially installed version.

I would expect running r10k deploy environment && r10k deploy module boolean to update the adrien/boolean module to the latest version available on the Forge, just like it would a module installed from Git.

Thoughts?

When using r10k, it will install modules from the forge using the flag "--ignore-dependencies". Using git modules, dependencies are not installed either.

I have to manually track down dependencies, using grep on Modulefiles and adding them to the Puppetfile. I think it would be useful to have r10k resolve dependencies and install them also. What do you think?

Right now, r10k's very opinionated configuration management is not overridable. If we want to create more complex structures of modules such proposed here: http://somethingsinistral.net/blog/configuration-management-as-legos/

In our environment we'd like to do something like that, however a configuration of:

:cachedir: '/var/cache/r10k'
:sources:
  :modules:
    remote: 'git@my-org/puppet-modules'
    basedir: '/etc/puppet/modules'
  :site:
    remote: 'git@my-org/puppet-site'
    basedir: '/etc/puppet/site'
  :projects: 'git@my-org/puppet-projects'
    basedir: '/etc/puppet/projects'

:purgedirs:
  - '/etc/puppet/modules'
  - '/etc/puppet/site'
  - '/etc/puppet/projects'

will create a very nested directory structure. It would be nice if it r10k simply cloned the envs into: /etc/puppet/modules/$environments instead of creating /etc/puppet/modules/modules/$environments -- say, with a switch for "shallow: true", or alternatively, if we could tell it to put the sites into "/etc/puppet/$environment/sites". (although I wouldn't know what kind of configuration scheme to use here)

We are aware that this would break full compatibility with librarian-puppet. This is something that r10k users would have to opt into.

It appears that if you have multiple sources/apps defined and a branch has the same name in both sources then it tries to merge the two branches together under one environment which gets messy. After a few tests it does not create two separate environments.

The preferred method for handling this would be to append the repo's name to the branch name and name the environment $repo_$branch. This way dynamic environments can be created by separate application owners without worrying about not re-using a branch name.

r10k relies on having the puppet module tool available to interact with modules installed from the forge. This adds an external dependency and means that required fixes like module permissions have to be handled through that external tool. It would be a Nice Thing (TM) if r10k directly managed these modules instead of shelling out.

I'm not sure exactly how to phrase this feature request, but here goes. It would be cool if you were able to set a reference to track a branch in the requested repo that matched the branch that r10k was checking out.

So for example if setting something like this, in the "development" branch would track a branch called "development" in puppet-filemapper. If the environment directory is master, then track master in the puppet-filemapper repo, and so on.

mod 'filemapper',
:git => 'git://github.com/adrienthebo/puppet-filemapper.git',
:ref => 'environment'

# The location to use for storing cached Git repos
:cachedir: '/var/tmp/r10k-cache'

# A list of git repositories to create
:sources:
  :modules:
    remote: 'git@panic:puppet-modules'
    basedir: '/tmp/puppet/modules'

# This directory will be purged of any directory that doesn't map to a
# git branch
:purgedirs:
  - '/tmp/puppet/modules'

With Puppetfiles ala

moduledir 'production'

forge "http://forge.puppetlabs.com"

mod 'puppetlabs/mysql', "0.6.1"
mod 'puppetlabs/nodejs', "0.2.1"
mod 'puppetlabs/stdlib', "3.2.0"
mod 'puppetlabs/vcsrepo', "0.1.1"
mod 'ripienaar/concat', "0.2.0"
mod "ispavailability/elasticsearch", "0.0.7"

mod "composer",
:git => "git@panic:puppet-composer"

mod "git",
:git => "git@panic:puppet-git"

mod "gitpubsub",
:git => "git@panic:puppet-gitpubsub"

results in r10k deploying those modules into $PWD/production/

See this gist for a complete example: https://gist.github.com/igalic/5767142

r10k will install incorrect versions of a module if you specify a version like 0.3.0 but 0.3.0-rc1 is available.

[R10K::Module::Forge - DEBUG] Module adrien/network is installed but doesn't match version v0.3.0, upgrading
[R10K::Module::Forge - DEBUG1] Execute: puppet module --modulepath '/etc/puppet/environments/strings_attached/modules' upgrade --version=v0.3.0 --ignore-dependencies adrien/network
[R10K::Module::Forge - DEBUG2] [puppet module upgrade --version=v0.3.0 --ignore-dependencies adrien/network, modulepath: "/etc/puppet/environments/strings_attached/modules"] STDOUT: Notice: Preparing to upgrade 'adrien-network' ...
Notice: Found 'adrien-network' (v0.3.0-rc1) in /etc/puppet/environments/strings_attached/modules ...
Notice: Downloading from https://forge.puppetlabs.com ...
[R10K::Module::Forge - DEBUG2] [puppet module upgrade --version=v0.3.0 --ignore-dependencies adrien/network, modulepath: "/etc/puppet/environments/strings_attached/modules"] STDERR: Error: Could not upgrade module 'adrien-network' (v0.3.0-rc1 -> v0.3.0)
  The installed version is already the best fit for the current dependencies
    You specified 'adrien-network' (v0.3.0)
    Use `puppet module install --force` to re-install this module

I expect this may be a configuration error of some kind, but I can't figure out what's going on.

Running r10k synchronize produces the following output:

Runtime error: #<NoMethodError: undefined method `instance' for R10K::Deployment:Class>

Other commands, such as r10k environment list return the same.

I can get r10k puppetfile install to work in a folder containing an environment that I check out manually. This installs the modules specified in the Puppetfile to modules/, as expected.

Background: I'm trying to get r10k setup on our Puppet master. We already have a setup where git branches equal environments, and where creation and destruction of environments is handled by a git hook. I'm hoping to replace this hook with r10k synchronize.

This is on an updated Ubuntu 12.04, and I installed r10k by cloning the git repo as of today, doing a gem build and installing the resulting gem. Installation seems to have worked fine.

My /etc/r10k.yaml contains the following:

:cachedir: '/var/cache/r10k'

:sources:
  :plops:
    remote: '/srv/puppet.git'
    basedir: '/etc/puppet/environments'

:purgedirs:
  - '/etc/puppet/environments'

Our Puppet repo that contains the environments is located at /srv/puppet.git on the same server, and is a bare repo. I have tried variations of paths and file:// URLs, but this doesn't seem to make a difference.

Any clue what's going on here?

The help states that to have more details we can use options -v or --verbose

-v --verbose    Set verbosity level

But with these options it dies with

Error while running: #<RuntimeError: Unrecognized options: verbose>

On IRC codec found that a workaround is to use

r10k -v 0 puppetfile install

We're pretty heavily invested in Puppet Librarian right now, but I'd like to switch over to r10k and take advantages it's ability to deploy environments.

It is possible to use it as somewhat of a drop in replacement for librarian? At leave I believe I read that somewhere.

I'm having a heck of a time getting it going. It'd be nice if there was a little more documentation around that. Also there's really no documentation on the config file, and options supported in it.

I am using r10k in combination with a gitflow-enabled repository. I would like to maintain the 'master' branch naming convention for the purpose of distributing production-ready code while sidestepping Puppet's lack of support for environments named 'master.'

This may be a hackish workaround, but having a symlink at /etc/puppet/environments/production that points to /etc/puppet/environments/master yields the behavior I want. My problem is that whenever r10k deploy environment is called, r10k deletes the symlink even if the purgedirs directive is commented out or not present (see this gist for an example).

I propose that the ability to:

• cleanly disable purgedirs behavior via multiple interfaces (persistently via a configuration file, temporarily via command line), and
• 'whitelist' files from being purged from the basedir (.r10kignore?)

are desirable features.

Using a Puppetfile with modules in private git repositories using SSH requires using a SSH private key.

Using the "deploy key" feature in Github and Github Enterprise will grant access to repositories for machines. It disallows duplicate SSH keys accross the entire site. Each repository needs to have it's separate deploy key.

This could be solved by generating multiple keys, one per repository, and speficying the SSH key to git when fetching.

Example config:

mod 'site-nrpe',
    :git => '[email protected]:organization/puppet-site-nrpe.git',
    :sshkey_path => '/var/opt/lib/r10k/.ssh/puppet-site-nrpe_id_rsa'

What do you think?

If I run r10k without a config file in the default location and without passing it the config file parameter I get:
Runtime error: TypeError: can't convert nil into String

However, if I pass an invalid location for a config file I get a better error:
Runtime error: Errno::ENOENT: No such file or directory - /etc/r30k.yaml

/var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/git/working_dir.rb:19: uninitialized constant R10K::Git::WorkingDir::Forwardable (NameError)
    from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require'
    from /usr/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:36:in `require'
    from /var/lib/gems/1.8/gems/r10k-0.0.10/lib/r10k/module/git.rb:3

Full trace: https://gist.github.com/larstobi/5337226
From Ubuntu Precise LTS.

cri doesn't support multiple flags like -vvvv, and log4r has the reverse handling of what people would expect. Thus setting a higher verbosity would mean doing -v 1 and a lower verbosity would be -v 6. This should be cleaned up.

Running "r10k cache" fails when running the first time and subsequently when running "r10k synchronize" with the same error message: exit code 128.

I have set up the r10k-shared git repo with root's ssh pubkey as a deploy key in github. The r10k-shared repository and the rsyslog repository are checked out in their respective places.

Apparently the cache remote ref is not being set for checked out modules:

root@master:/etc/puppetlabs/puppet/environments/master/modules/rsyslog# git remote -v
origin  git://github.com/puppetlabs-operations/puppet-rsyslog.git (fetch)
origin  git://github.com/puppetlabs-operations/puppet-rsyslog.git (push)

OS: Ubuntu Presice 64

Detailed info in: https://gist.github.com/larstobi/5309639

We are currently having the following problem.

If we specify more than one git repo in our yaml file it will purge out the directories right after deploying them.

e.g.
...
[R10K::Task::Module::Sync - INFO] Deploying fedora into /etc/puppet/environments/metro/modules
[R10K::Task::Module::Sync - INFO] Deploying stackbase into /etc/puppet/environments/metro/modules
[R10K::Task::Deployment::PurgeEnvironments - INFO] Purging stale environments from /etc/puppet/environments
[R10K::Task::Deployment::PurgeEnvironments - INFO] Purging stale environments from /etc/puppet/environments

Here is our yaml file

# The location to use for storing cached Git repos
:cachedir: '/var/cache/r10k'

# A list of git repositories to create
:sources:
 :metro:
   remote: '[email protected]:discoverygardenpuppet/env_metro.git'
   basedir: '/etc/puppet/environments'
 :env_ir:
   remote: '[email protected]:discoverygardenpuppet/env_ir.git'
   basedir: '/etc/puppet/environments'

:purgedirs:
  - '/etc/puppet/environments'

If we comment out either one and rerun it deploys fine and doesn't delete them after. I have tried deleting the /var/cache/r10k as well and it has no impact.

Sometimes modules have transient failures. This might be caused by bugs in Github or by other reasons, such as bad company proxies or network issues.

When r10k experiences a "git fetch" failure, or a "puppet module install" failure, for certain error types, it should mark the module for a retry or two.

As discussed in IRC, consider the following scenario. R10k manages modules in /etc/puppet/environments/$environment/modules, in our case via a Puppetfile. Someone unwisely edits /etc/puppet/environments/production/modules/foo/manifests/init.pp directly on the Puppetmaster server (but doesn't commit the changes), so the local working tree of that module is now dirty.

I believe running r10k deploy environment && r10k deploy module foo should reset that dirty working tree, just like it would reset the module's branch if it were not in sync with the remote branch.

[R10K::Synchro::Git - ERROR] Could not resolve ref "365392b8f7c9d4be86cdf5e2d3c8df32965382df" for git cache /var/cache/r10k/git---github.com-puppetlabs-operations-puppetlabs-activemq.git
[R10K::Action::Environment::Deploy - ERROR] Could not synchronize /opt/puppet/environments/production: "git --git-dir /var/cache/r10k/git---github.com-puppetlabs-operations-puppetlabs-activemq.git rev-parse 365392b8f7c9d4be86cdf5e2d3c8df32965382df^{commit}" returned with non-zero exit value 128
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/synchro/git.rb:222:in git' /var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/synchro/git.rb:170:inresolve_commit'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/synchro/git.rb:154:in reset' /var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/synchro/git.rb:73:insync'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/module/git.rb:22:in sync!' /var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/root.rb:40:inblock in sync_modules!'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/root.rb:39:in each' /var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/root.rb:39:insync_modules!'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/root.rb:35:in sync!' /var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/action/environment.rb:32:incall'
/var/lib/gems/1.9.1/gems/middleware-0.1.0/lib/middleware/runner.rb:31:in call' /var/lib/gems/1.9.1/gems/middleware-0.1.0/lib/middleware/builder.rb:102:incall'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/lib/r10k/cli/environment/deploy.rb:42:in block (2 levels) in command' /var/lib/gems/1.9.1/gems/cri-2.3.0/lib/cri/command.rb:296:incall'
/var/lib/gems/1.9.1/gems/cri-2.3.0/lib/cri/command.rb:296:in run_this' /var/lib/gems/1.9.1/gems/cri-2.3.0/lib/cri/command.rb:249:inrun'
/var/lib/gems/1.9.1/gems/cri-2.3.0/lib/cri/command.rb:262:in run' /var/lib/gems/1.9.1/gems/cri-2.3.0/lib/cri/command.rb:262:inrun'
/var/lib/gems/1.9.1/gems/r10k-0.0.9/bin/r10k:7:in <top (required)>' /usr/local/bin/r10k:23:inload'
/usr/local/bin/r10k:23:in `

The README doesn't provide any information on how to get started with r10k.

Although it would be somehow a cool feature to have r10k bootstrap it self somehow, it should at least provide some basic information on how to install it.

I don't think everyone can figure it out that it can be installed as "gem".

When attempting to use a path with a git repo, puppetfile install copies the entire repo and not what's under the path specified.

The Forge and Git modules don't take into consideration that an existing module might be switched from one to the other. As such, doing this could make things explode pretty badly. Modules should be able to determine if they need to wipe an existing directory when installing or updating.

This issue addresses the problem raised in #2 (comment)

When checking out an environment you don't necessarily need anything but the last commit. It might make r10k faster to allow shallow clones.

When a defined remote doesn't exist, the thrown error message is not really helpful:

r10k.yaml

:sources:
    :mysource:
        remote: '/some/non/existing/directory.git'
        basedir: '/etc/puppet/environments'

r10k deploy environment runs into this error message:

[R10K::TaskRunner - ERROR] Task #<R10K::Task::Deployment::DeployEnvironments:0x00000001efaa00> failed while running: "git clone --mirror /some/non/existing/directory.git/ /var/cache/r10k/-some-non-existing-directory.git" returned with non-zero exit value 128

I don't know whether there's a straightforward way to handle this more gracefully, but the current error message is not really helpful either.

Right now the cache command has poor documentation and only updates a single repository. Either it should update all repositories and have better help, or be removed.

The json dependency adds a hard requirement on ruby headers and a compiler, which adds a lot of overhead. When installing it without these dependencies available, gem explodes:

ERROR:  Error installing r10k:
        ERROR: Failed to build gem native extension.
        /opt/puppet/bin/ruby extconf.rb
mkmf.rb can't find header files for ruby at /opt/puppet/lib/ruby/ruby.h