summaryrefslogtreecommitdiff
path: root/spec/integration/environments/default_manifest_spec.rb
AgeCommit message (Collapse)AuthorFilesLines
2014-09-09(PUP-3162) Switch to a whitelist for $environment interpolationJosh Partlow1-10/+0
Previous commit blacklisted a small set of settings from having $environment interpolated. After some discussion, we decided to broaden this to a whitelist, and the only setting we can currently think of needing $environment interpolation when using directory environments is config_version. We also decided to not halt startup for default_manifest with $environment in it, as these errors are difficult to read with the current error reporting from a rack master. So the validation for default_manifest is removed.
2014-09-08(maint) Remove unused constant from default_manifest_specJosh Partlow1-1/+0
2014-09-02(maint) Namespace constant declaration in specs to prevent warningsJosh Partlow1-2/+4
Add module namespacing to two specs declaring an FS constant (for convenience) so that we don't receive warnings about the duplicate declaration.
2014-08-29(PUP-3069) Test both future and current parser with default_manifestJosh Partlow1-170/+186
Previously the environments/default_manifest_spec.rb was only running with the current parser. This runs the set of tests for both the future and current parser cases.
2014-08-29(PUP-3069) Change restrict_environment_manifest nameJosh Partlow1-7/+7
After discussion with Nick Fagerlund and Henrik Lindberg, changing restrict_environment_manifest setting to disable_per_environment_manifest to more clearly reflect what the setting does.
2014-08-29(PUP-3069) Add an integration spec for default_manifestJosh Partlow1-0/+256
This adds integration testing of the new default_manifest and restrict_environment_manifest settings. It tests all the way from Puppet initialization from actual puppet.conf files and environment/manifest files through catalog compilation, simulating Puppet master activity. Since these settings are purely server-side constructs, in that they do not impact the agent beyond the contents of the final catalog the agent receives, I believe this is sufficient to validate them.