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>
Previous, require_controls was including all controls from the named
profile, despite the documented behavior being that it only includes
controls explicitly pulled in by the user. The cause was two-fold:
1) A previous refactor meant that we weren't removing the rule from the
correct context, and
2) We weren't descending down the dependency tree when filtering rules.
This commit fixes the require_controls DSL method and adds a test to
help prevent future regressions.
Signed-off-by: Steven Danna <steve@chef.io>
If a URL based source does not match the shasum recorded in the
lockfile, it likely means a new version has been pushed to the remote
source. In this case, we fail to help ensure that when using a lockfile
we always run the same code as when the lockfile was created.
Signed-off-by: Steven Danna <steve@chef.io>
All resources from deps are added into the control_eval_context used by
the current profile. However, if there is a name conflict, the last
loaded resource wins. The new `require_resource` dsl method allows the
user to do the following:
require_resource(profile: 'profile_name',
resource: 'other',
as: 'renamed')
describe renamed do
...
end
Signed-off-by: Steven Danna <steve@chef.io>
