Display / capture coloured output in post-provision run

[madAndroid]

Firstly, great plugin, thanks very much for putting this together!

I'm currently using this to implement ServerSpec tests directly following a successful puppet provisioning run ... and it would be awesome if the plugin were able to maintain/preserve the coloured output of the ServerSpec run, to make the output easier to read at first glance. We use the standard shell provisioner to execute the puppet run, and this preserves the coloured output of puppet's resource management.

The Vagrant documentation suggests setting keep_color bool to true to preserve the native script output colour, and this appears to be the default .. is there perhaps a way to default this to true for the vagrant-trigger run as well?

Is this a feature that you would potentially support at some point? If the behaviour I'm experiencing is not expected, are there any configuration options I can set to ensure coloured output is preserved?

Thanks in advance :)

[emyl]

Hello,

In version 0.5.0 I've made some changes in how the plugin uses the Vagrant UI. Please, could you check if by chance this issue have been automagically solved?

Thanks.

[madAndroid]

Hi,

Thanks for looking into this .. I'm afraid there's been no change on the colour front .. and I'm not sure if this is related to the recent changes, but it appears as though the behaviour has changed slightly: for some reason the trigger is attempting another 'up' action when run.. for example:

with a trigger set as:

if Vagrant.has_plugin?("vagrant-triggers")
    vm_cfg.trigger.after [:up, :provision],
        :stdout => true,
        :force => true do
        run "rake spec:#{name}"
    end
end

The plugin appears to run

❯❯❯ vagrant up auth_core
Bringing machine 'auth_core' up with 'virtualbox' provider...
==> auth_core: VirtualBox VM is already running.
==> auth_core: Running triggers after up...
==> auth_core: Executing command "rake spec:auth_core"...
==> auth_core: An action 'up' was attempted on the machine 'auth_core',
==> auth_core: but another process is already executing an action on the machine.
==> auth_core: Vagrant locks each machine for access by only one process at a time.
==> auth_core: Please wait until the other Vagrant process finishes modifying this
==> auth_core: machine, then try again.
==> auth_core:
==> auth_core: If you believe this message is in error, please check the process
==> auth_core: listing for any "ruby" or "vagrant" processes and kill them. Then
==> auth_core: try again.

I'm not entirely sure if the same behaviour was in effect previously, as it's been some time since I've been testing the serverspec triggers - but from memory this wasn't happening previously.

Versions: Vagrant: 1.6.5 (I've held off upgrading due to issues with Beaker and latest vagrant) Operating system: OSX 10.10

Should I be testing these latest changes against Vagrant 1.7.x ?

[emyl]

Hello,

I know it's an old thread, but I've finally made some efforts trying to reproduce the issue. Unfortunately everything looks good to me, as you can see from the following screenshot:

If you're still interested in the issue and you have a reproducible case, could you please share it?