When in inspec shell, you need to type the `help` command to find out info
about your target system. This info would be super helpful right out of the
gate so users have confidence that they're targeting the correct system.
The target info is still available via the `help` command as it always has
been, as well.
Signed-off-by: Adam Leff <adam@leff.co>
The inline docs for SourceReaders::InspecReader#new state that it takes
a SourceReader object for the target... but we're trying to create the
SourceReader object! It actually takes a FileProvider object that is
capabile of listing files for the given profile and reading them.
Signed-off-by: Adam Leff <adam@leff.co>
The crontab resource parses a particular user's crontab file into
individual entries and allows the user to assert information about
each entry as needed.
Signed-off-by: Adam Leff <adam@leff.co>
The other Chef tooling (chef-client, chef, kitchen, berks, etc.)
support a `-v` flag to display the version. Currently, inspec
errors out with the following error:
```
Could not find command "_v".
```
This adds a Thor map so that `-v` executes the `version` command.
Signed-off-by: Adam Leff <adam@leff.co>
The existing slack form on the community page doesn't function...
it's trying to post to the community-slack.chef.io site, but the actual
invite form doesn't actually live there but rather in a SlackIn app.
Also, we have some info we'd like new Slack users to receive, such as
etiquette tips and code-of-conduct information.
This change replaces the form with a link to the community-slack.chef.io
site. Also, I fixed a missing space in the surprise code example on
the main page.
Signed-off-by: Adam Leff <adam@leff.co>
This pull request adds a packages resource so that we can check for pattern matches against all the packages on a system. This initially implements only dpkg support for debian-based platforms so we can cover this use case:
```ruby
describe packages(/^xserver-xorg.*/) do
its("list") { should be_empty }
end
```
This uses FilterTable so we can supply additional queries, too.
```ruby
describe packages(/vi.+/).where { status != 'installed' } do
its('statuses') { should be_empty }
end
```
Users can specify the name as a string or a regular expression. If it is a string, we will escape it and convert it to a regular expression to use in matching against the full returned list of packages. If it is a regular expression, we take that as is and use it to filter the results.
While some package management systems such as `dpkg` can take a shell glob argument to filter their results, we eschew this and require a regular expression to match multiple package names because we will need this to work across other platforms in the future. This means that the following:
```ruby
packages("vim")
```
Will return *all* the "vim" packages on the system. The `packages` resource will take `"vim"`, turn it into `/vim/`, and greedily match anything with "vim" in the name. To match only a single package named `vim`, it needs to be an anchored regular expression.
```ruby
packages(/^vim$/)
```
Signed-off-by: Joshua Timberman <joshua@chef.io>
Use entries instead of list
Added a few more tests and non installed package in output
Signed-off-by: Alex Pop <apop@chef.io>
fix lint
Signed-off-by: Alex Pop <apop@chef.io>
Signed-off-by: Joshua Timberman <joshua@chef.io>
