| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
absolutely hard requirement on the fixes that went into chef-config 2.2.11, so the
floor of that gem is bumped up.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently rubocop thinks the default behavior should be that we have to
rewrite every use of `foo == 0` into `foo.zero?` which is a big pile of
NOPE for me. After discovering that `.zero?` is actually slower, I'd
prefer to go the other direction. Same for `positive?` and
`negative?`.
These are the only uses of `zero?` in the chef/chef codebase, while I'm
pretty sure the inverse rule would touch nearly every file.
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4174 Style/SpaceInsideHashLiteralBraces
1860 Style/SpaceAroundOperators
1336 Style/SpaceInsideBlockBraces
1292 Style/AlignHash
997 Style/SpaceAfterComma
860 Style/SpaceAroundEqualsInParameterDefault
310 Style/EmptyLines
294 Style/IndentationConsistency
267 Style/TrailingWhitespace
238 Style/ExtraSpacing
212 Style/SpaceBeforeBlockBraces
166 Style/MultilineOperationIndentation
144 Style/TrailingBlankLines
120 Style/EmptyLineBetweenDefs
101 Style/IndentationWidth
82 Style/SpaceAroundBlockParameters
40 Style/EmptyLinesAroundMethodBody
29 Style/EmptyLinesAroundAccessModifier
1 Style/RescueEnsureAlignment
|
|
|
| |
Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"
|
|
|
| |
Created via git ls-files | xargs perl -pi -e "s/(Copyright.*?), Opscode(,)? Inc(\.)?/\\1, Chef Software Inc./gi"
|
|
|
| |
Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"
|
|
|
|
|
|
|
| |
This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.
|
|
|
|
|
|
|
| |
with validation off any bad utf8 data will not cause the
ffi-yajl encoder to raise. with ffi-yajl >= 2.2.0 the bad
data will be scrubbed to produce valid JSON to POST/PUT to
the server.
|
|
|
|
|
|
|
|
| |
* JSONInput middleware now checks the incoming headers for a
Content-Type; if set to a non-json type, the body is passed through
unchanged. This allows us to use our normal HTTP client objects to
make requests with non-JSON bodies, such as file uploads.
* Add test coverage for the JSONInput middleware.
|
| |
|
| |
|
|
|