delta/ruby-gems/chef.git/spec/unit/application, branch https

Pick some of the unit test fixes from #10068

2020-06-26T17:20:50+00:00

This picks some of the more obviously correct looking fixes from #10068

Signed-off-by: Lamont Granquist

Knife bootstrap options cleanup

2020-04-17T17:20:31+00:00

We have issue that are caused by old code before merging of hash values
were done correctly.

The `config` hash correctly merges all options and should always be
used.

Knife plugins should never touch Chef::Config[:knife] values (either
reading or writing from them).

The `knife_config` should be converted to the `config` hash since it
directly accesses Chef::Config[:knife] values.

The `config_value()` helper should no longer be used.  Very clearly most
people started to use that when they should just use the config hash
directly.  That was intended to be used only when a knife cli option
was being renamed and the former configuration value needed to be
used as well.  It has been cargo culted around as the way to access
config values, and that should really stop.

The DataBagSecretOption mixin has been cleaned up so that the cli
options read+write only to the config[:cl_secret] and
config[:cl_secret_file] values.  The config file values go into
config[:secret] and config[:secret_file].  The fact that those are
the merged values in the `config` hash doesn't matter since only
the cli should be writing to the first two and only the config
file should be writing to the latter two.  I don't know why it was
made so complicated to begin with, but if there's some hidden
chef-11.early backcompat there, then chef-16 deliberately breaks that.

The use of `locate_config_value` helpers in all knife plugins is also
discouraged (but they all implement those themselves), just use the
config hash, which has the correct hash merge ordering.  All of those
need to be deleted.

Signed-off-by: Lamont Granquist

Remove copyright dates

2020-04-13T22:47:17+00:00

Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.

Signed-off-by: Lamont Granquist

Simplify YAML mode checking for chef-apply

2020-03-23T16:57:09+00:00

Signed-off-by: Bryan McLellan

Add YAML support to 'chef-apply'

2020-03-23T16:57:09+00:00

Allows `chef-apply foo.yml` to be parsed as a YAML recipe.
Also adds a configuration flag to enable `chef-apply foo.whatever --yaml`.

Signed-off-by: Bryan McLellan

Add chef-utils gem with various recipe DSL helpers

2019-11-08T22:06:33+00:00

This is the implementation of [RFC-087](https://github.com/chef-boneyard/chef-rfc/blob/master/rfc087-distro-sugar-helpers.md)
although some of the specifics have been iterated on and changed.

The documentation will be in the [README.md](https://github.com/chef/chef/tree/master/chef-utils/README.md) once this is merged.

While this PR mostly moves chef-sugar utilities into core-chef via this chef-utils gem, the scope of the chef-utils gem
should be considered larger than just that. As an example this PR moves the Mash class into this gem for reuse in ohai
as well.

Signed-off-by: Lamont Granquist

Add format supported option in values

2019-10-27T21:10:44+00:00

Signed-off-by: Vivek Singh

text updated on windows

2019-08-28T18:26:01+00:00

Signed-off-by: Lamont Granquist

fail on interval runs on windows

2019-08-28T17:53:34+00:00

Signed-off-by: Lamont Granquist

fix 4 cops

2019-07-05T20:41:00+00:00

- Layout/MultilineMethodCallBraceLayout
- Layout/ClosingParenthesisIndentation
- Layout/IndentFirstArgument
  EnforcedStyle: consistent
- Layout/BlockEndNewline

the first of these autocorrected to horrible looking code which exposed
that we really needed the other three as well, which also cleaned up a
bunch of other terrible looking code.

Signed-off-by: Lamont Granquist