Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

r10k deploy [environment|module] does not deploy modules #26

Closed
larstobi opened this issue May 13, 2013 · 4 comments
Closed

r10k deploy [environment|module] does not deploy modules #26

larstobi opened this issue May 13, 2013 · 4 comments
Labels
Milestone

Comments

@larstobi
Copy link

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

@adrienthebo
Copy link
Contributor

By default r10k deploy environment doesn't deploy modules in the Puppetfile, because that can be an incredibly long process. For instance, the repository that I'm testing against has over 2000 modules deployed into the environments. To enable updating modules from the Puppetfile you can pass the -p flag to r10k deploy environment which will deploy all modules in all Puppetfiles. This is equivalent to the old behavior of r10k synchronize.

This is definitely an issue because I haven't made this distinction terribly clear in the documentation. How would you like this behavior to be displayed? Would you like to have a specific command equivalent to the old synchronize command that would do the recursive deployment? Would documentation be sufficient? What would be the most clear way to handle recursive deployments like this?

@larstobi
Copy link
Author

Ah, I see. The reason I didn't catch the -p flag was that I didn't realize that there was another level of help text at "r10k deploy environment --help", where it is nicely explained, and it works nicely. I don't require any more documentation than that.

By the way, did you notice that the OPTIONS section alternates randomly between being right after the USAGE section and being last? Not really a problem, but it is surprising.

root@master:/etc/puppetlabs/puppet/environments# r10k deploy environment --help
NAME
environment - deploy environments and their dependent modules

USAGE
    r10k deploy environment <options> <environment>
    <...>

OPTIONS
    -p --puppetfile    Deploy modules from a puppetfile

OPTIONS FOR DEPLOY
    -c --config        Specify a configuration file
    -c --config        Specify a configuration file
    -h --help          show help for this command
    -t --trace         Display stack traces on application crash
    -v --verbose       Set verbosity level
root@master:/etc/puppetlabs/puppet/environments# r10k deploy environment --help
NAME
    environment - deploy environments and their dependent modules

USAGE
    r10k deploy environment <options> <environment>
    <...>

OPTIONS FOR DEPLOY
    -c --config        Specify a configuration file
    -c --config        Specify a configuration file
    -h --help          show help for this command
    -t --trace         Display stack traces on application crash
    -v --verbose       Set verbosity level

OPTIONS
    -p --puppetfile    Deploy modules from a puppetfile
root@master:/etc/puppetlabs/puppet/environments#

@adrienthebo
Copy link
Contributor

Well, that's really weird that those fields are flip-flopping. This will probably have to be fixed in upstream; I'll see if I can get that worked out before 1.1.0. Thanks for noting that!

@adrienthebo
Copy link
Contributor

I've reported this upstream in denisdefreyne/cri#14, since this is an upstream issue I'm going to close this issue in favor of the upstream one. @larstobi thanks again for reporting this!

sarameisburger pushed a commit to sarameisburger/r10k that referenced this issue Apr 12, 2019
…-custom-gem-path

Bugfix/3.8.x/remove custom gem path
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants