"r10k deploy display -p" doesn't reflect the actual status of the environments about r10k HOT 2 CLOSED

This requests a few features, I'll respond to them in turn.

Displaying the version of the module on disk as opposed to what's specified in the Puppetfile:

👍. I thought that I implemented things to show the currently installed version, but I must have been mistaken about that.

Displaying the module version/SHA:

This gets a little bit stickier. In theory I could see if any git tags matched the currently checked out branch, but that increases the complexity of this a bit. Cool feature, would be awesome to have, but I don't know how much this should be prioritized. 👍 for the idea though.

Command layout:

For the sake of sanity, every action needs to be under a subcommand. For instance, the deploy actions that use an r10k.yaml are entirely different from the puppetfile actions. They use the same underlying behavior but they aren't necessarily joined. Thus, doing r10k puppetfile display is going to be different from r10k deploy display. Does that make more sense?

r10k deploy status

👍 for the subcommand name.

However, everything has to be complicated. :) To correctly show if a module is out of date, you would have to fetch the latest information - and if you're operating on a lot of modules, this could take a while. If nothing else, this should preserve deploy display or a similar command so that you can see the status of things without doing a fetch.

Should a status command have a flag to determine if everything should be fetched beforehand?

command output:

👍 for color.

Formatting:

I was just going to go with yaml formatting in the general case. Is the real distinction on whether it r10k should output color/no color?

Also, thanks very much for submitting this awesome issue report! I really appreciate feedback like this!

from r10k.

Support for module expected/actual versions added in bd7ea47:

ops (/home/adrien/development/r10k/testing/deploy/ops/environments)
    - add_mysql_error_logs
        modules:
            - git
                actual: 13b2b8f0e93f3304f4b13c546246da7b51e78173
                expected: 13b2b8f0e93f3304f4b13c546246da7b51e78173
                type: git
            - hubot
                actual: 1ab6921e70ee1656ca753ea8c5f9591e8472eedb
                expected: 1ab6921e70ee1656ca753ea8c5f9591e8472eedb
                type: git

It doesn't encompass all of the behavior asked for in this ticket but it gets us a lot closer. I'm going to ship 1.4.0 with this behavior so that something can get out of the door; if additional functionality is required then we can incrementally revisit this and extend behavior in future releases.

from r10k.