delta/ruby-gems/chef.git/lib/chef/application.rb, branch ruby255 github.com: opscode/chef.git fixed review comments 2018-10-23T12:19:15+00:00 dheerajd-msys dheeraj.dubey@msystechnologies.com 2018-10-23T06:54:02+00:00 e8fa4f16e8a7a24b5d66e0beb5bb90dd74496190 Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com> 
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
fix duplicate logs 2018-10-23T06:54:27+00:00 dheerajd-msys dheeraj.dubey@msystechnologies.com 2018-09-27T12:10:53+00:00 68cada49a89f33b8d82e5ec080aa3fbd8b265831 Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com> 
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
fix logger logic with is_default? from new mixlib-config 2018-07-06T00:16:51+00:00 Lamont Granquist lamont@scriptkiddie.org 2018-07-06T00:16:51+00:00 d176c42c151fe37401bbe42a470ff90f6f4b20c2 Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org> 
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
Adding log_location_default? method 2018-07-06T00:15:22+00:00 Nolan Davidson ndavidson@chef.io 2018-07-03T15:40:59+00:00 1e241b3f4327dfad0c26d141fe64eacd1d89494b Checking the configurable for `:log_location` and comparing to the current setting. Calling `.inspect` on both to get a string representation of IO:STDOUT, as they have different object IDs and fail a direct comparison. Signed-off-by: Nolan Davidson <ndavidson@chef.io> 
Checking the configurable for `:log_location` and comparing to the
current setting. Calling `.inspect` on both to get a string
representation of IO:STDOUT, as they have different object IDs and fail
a direct comparison.

Signed-off-by: Nolan Davidson <ndavidson@chef.io>
Fix dupe stdout_logger 2018-07-06T00:15:22+00:00 Nolan Davidson ndavidson@chef.io 2018-06-28T15:45:06+00:00 a8f0583ce244896113f030564d204e4969b2c989 I _think_ this resolves issue #7184 Basically reverting back to the previous logic of `want_additional_logger?`. It was mentioned in the issue comments that the comparison against `STDOUT` wasn't working, but it seems to work for me currently on Centos7. Signed-off-by: Nolan Davidson <ndavidson@chef.io> 
I _think_ this resolves issue #7184

Basically reverting back to the previous logic of
`want_additional_logger?`. It was mentioned in the issue comments that
the comparison against `STDOUT` wasn't working, but it seems to work for
me currently on Centos7.

Signed-off-by: Nolan Davidson <ndavidson@chef.io>
Address possible gem installs between interval runs that are then used in the config. 2018-04-02T18:39:59+00:00 Noah Kantrowitz noah@coderanger.net 2018-04-02T18:39:59+00:00 e24e7fdb197815a5fb77f35c8ac058a870d67b36 Signed-off-by: Noah Kantrowitz <noah@coderanger.net> 
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
mechanical conversion of most debug log statements to trace 2018-03-26T17:34:39+00:00 Thom May thom@chef.io 2018-03-23T13:05:13+00:00 97c1dd6f1cac6d97e85d05039cad8b28596141ba Signed-off-by: Thom May <thom@chef.io> 
Signed-off-by: Thom May <thom@chef.io>
Add the ability to inject log objects 2018-03-19T21:36:23+00:00 Thom May thom@chef.io 2018-02-14T12:22:41+00:00 94222a8a0a1cda16d35c8f08c731a3f902449391 meaning that we can have inheritable metadata Signed-off-by: Thom May <thom@chef.io> 
meaning that we can have inheritable metadata

Signed-off-by: Thom May <thom@chef.io>
Stop mixlib-cli default clobbering mixlib-config settings 2018-02-27T04:32:51+00:00 Lamont Granquist lamont@scriptkiddie.org 2018-02-27T04:32:51+00:00 7a09548c07dc473c220cd9b4def190d53b7e8c0f The pre-14 precedence level is: 1. mixlib-cli setting 2. mixlib-cli default 3. mixlib-config setting 4. mixlib-config default This means that if an option has a mixlib-cli default that it cannot ever be set in the config file. This PR swaps 2+3 around: 1. mixlib-cli setting 2. mixlib-config setting 3. mixlib-cli default 4. mixlib-config default Now the mixlib-cli defaults still take precedence over mixlib-config defaults, but it is possible to set a value in config.rb if there's a mixlib-cli default setting (which creeps into the settings in hidden ways if you just use `boolean: true` in mixlib-cli). Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org> 
The pre-14 precedence level is:

1. mixlib-cli setting
2. mixlib-cli default
3. mixlib-config setting
4. mixlib-config default

This means that if an option has a mixlib-cli default that it cannot
ever be set in the config file.

This PR swaps 2+3 around:

1. mixlib-cli setting
2. mixlib-config setting
3. mixlib-cli default
4. mixlib-config default

Now the mixlib-cli defaults still take precedence over mixlib-config
defaults, but it is possible to set a value in config.rb if there's
a mixlib-cli default setting (which creeps into the settings in hidden
ways if you just use `boolean: true` in mixlib-cli).

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
fix double-logging bug 2018-01-18T22:05:13+00:00 Lamont Granquist lamont@scriptkiddie.org 2018-01-18T22:05:13+00:00 1417310f306571c90977cbe1c4e145d18f0f13d8 somehow we're getting an IO object here which is a STDOUT wired up to file descriptor 10 which is not the same as "STDOUT" which is wired up to file descriptor 1. i can't track down where or how this is happening. this works around the problem by just inspecting if the log_location is set to an IO object which is a tty or not which should be broadly equivalent (and perhaps more correct than the old code? not sure if the edge cases matter or not). also i'm not smart enough right now to figure out how to test this adequately, particularly in ways that would actually catch if it really breaks in the future (particularly due to the gnarliness of wanting to have a functional test which constructs a tty when run on travis without a tty....) Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org> 
somehow we're getting an IO object here which is a STDOUT wired up to
file descriptor 10 which is not the same as "STDOUT" which is wired up
to file descriptor 1.

i can't track down where or how this is happening.

this works around the problem by just inspecting if the log_location is
set to an IO object which is a tty or not which should be broadly
equivalent (and perhaps more correct than the old code?  not sure if
the edge cases matter or not).

also i'm not smart enough right now to figure out how to test this
adequately, particularly in ways that would actually catch if it
really breaks in the future (particularly due to the gnarliness of
wanting to have a functional test which constructs a tty when run on
travis without a tty....)

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>