* Add audit integration testing.
* Add some docs and feedback changes.
* Updated integration task to use paramaters and clean it up.
* Fix unit test
Signed-off-by: Jared Quick <jquick@chef.io>
Functional tests can sometimes be picky. Moving them to their own
matrix item so they're smaller and faster to re-run if needed.
Signed-off-by: Adam Leff <adam@leff.co>
* Require Ruby 2.3 and later
Ruby 2.1 is EOL, and Ruby 2.2 is on security fixes only. This moves
InSpec to support the current "normal maintenance" versions of Ruby
like Chef does and also bumps the versions used in Travis tests.
Signed-off-by: Adam Leff <adam@leff.co>
* Remove Ruby 2.2 from appveyor
Signed-off-by: Adam Leff <adam@leff.co>
* Remove test/resources directory, update README
The test/resources directory is stale and no longer used. Rather, we
favor Test Kitchen-backed integration tests in test/integration.
This change removes the stale tests and updates the README accordingly.
Signed-off-by: Adam Leff <adam@leff.co>
* Remove resources tests from travis
Signed-off-by: Adam Leff <adam@leff.co>
I must've been dealing with some fun travis caching because
after my last change was merged, this travis job disappeared.
The .travis.yml config I used was wrong... this should do it.
Signed-off-by: Adam Leff <adam@leff.co>
The website acceptance job in Travis will fail for non-chef-github
users because we use encrypted environment variables. This job
should never hold up an accepted PR, so I'm moving it to the
allowed_failures section.
Signed-off-by: Adam Leff <adam@leff.co>
If changes are detected in the docs or www directory, a website
build will be generated that pushes up to Netlify. This will allow
teams to validate web changes without requiring pulling down the
branch and building locally.
Signed-off-by: Adam Leff <adam@leff.co>
Using the `env` feature of the matrix builds is a little hack so that
one can quickly see what tests failed when looking at the build summary
page.
Signed-off-by: Steven Danna <steve@chef.io>
Without this, Travis often ends up running 2 CI jobs for updates to a
PR: 1 for the update to the PR, 1 for the push to the branch.
By adding this bit of config, travis will still run a job for any update
to a PR, but won't run a duplicate job for the push to the branch that
the PR is based off of. We use this in chef/chef and chef/chef-server
to reduce unnecessary use of TravisCI resource.
