Add a transitive test property #821
Conversation
|
Thanks for highlighting this @ekohl. Let me run this past a few colleagues, but it would seem logical that the test framework is behaving the same way as Puppet behaves, at least. However, we can start a separate conversation with the Puppet core team if you feel there's an issue with how chained notifies are working at the moment? |
|
I would like a formal statement from the core team how they think it should work. From there we can decide how to approach this. |
|
I pinged some of my colleagues from the agent team and they believe that |
|
It is my impression that it relies on some resource triggering the notify. So if you have: Class['A'] ~> Class['B'] ~> Class['C']Then it works if there's a resource inside |
(rodjekGH-6) Set up GH Action for testing
(rodjekGH-7) Removal of Appveyor and Travis CI jobs
Add Ruby 3 support
(rodjekGH-5) Release prep for 2.10.0
Starting with versions 7.12.0/6.25.0, Puppet was changed not to directly depend on Facter anymore, but to use a `Puppet::Runtime` implementation instead (e.g. calls to `Facter` were changed to `Puppet.runtime[:facter]` to allow for pluggable Facter backends). rspec-puppet stubs facts from facterdb by setting custom facts with higher weights, meaning that Facter 4 will still resolve the underlying core facts (which is by design), leading to noticeable performance hits when compiling catalogs with Facter 4 as opposed to Facter 2 (which just returned the custom fact). This means we can achieve a pretty big performance improvement with rspec-puppet by registering a custom Facter implementation that bypasses Facter altogether and just saves facts to hash. This behavior cand be activated by setting `facter_implementation` to `rspec` in `RSpec.configure`. By default, the setting has the value of `facter` which maintains the old behavior of going through Facter. If `rspec` is set but the Puppet version does not support Facter implementations, rspec will warn and fall back to using Facter.
Add setting to use custom Facter implementation
Release Prep for 2.11.0
Using the 'rspec' facter implementation we could sometimes get in a case where the values of FacterImpl and Puppet.runtime[:facter] diverged between example groups. Because rspec-puppet overrides facts using the FacterImpl constant (which is only set once), Puppet.runtime[:facter] would point to a different instance of FacterTestImpl with no available facts, causing calls to Puppet.runtime[:facter].value to fail. To prevent this from happening, set Puppet.runtime[:facter] to the value of FacterImpl; this way we make sure Puppet.runtime[:facter] and FacterImpl operate on the same instance of FacterTestImpl.
Ensure FacterImpl consistency between example groups
…p_2_11_1 (MAINT) Release prep for v2.11.1
…gelog_index (MAINT) Add v2.11.1 entry to docs/changelog/index.md
With Puppet you can write:
Class['A'] ~> Class['B'] ~> Class['C']
This implies Class['A'] ~> Class['C'] and rspec-puppet actually will
tell you that chaining is there, but it doesn't actually happen. This
was reported in rodjek/rspec-puppet#821.
In this particular case it means that if DB seeding doesn't happen then
the apipie caches indexes aren't refreshed. By chaining it to db:migrate
there's a much bigger chance it actually happens.
Normally apipie:cache:index needs to run after a package is updated so
ideally this would actually be done in packaging, but this is the
workaround we've been using for a long time.
|
@sanfrancrisko was there ever any progress on this discussion? We've just hit this problem again and while re-reading https://puppet.com/docs/puppet/7/lang_relationships.html#lang_rel_chaining_arrows I can't really tell if More explicitly, the chaining example says "Resource declarations can be chained. That means you can use chaining arrows to make Puppet apply a section of code in the order that it is written. This example applies configuration to the package, the file, and the service, in that order, with each related resource notifying the next of any changes" (emph. mine) where one could interpret "any changes" as "any changes to itself" and not "any changes in the whole chain". |
When encountering results containing nil from an autorequire-family call, Puppet will skip over them without error but rspec-puppet results in an error. This aligns rspec-puppet with Puppet's behavior. Also, rename the autorelationships spec test so that it runs properly as part of a 'rake spec' invocation.
Use notify, an OS-neutral resource type, instead of File for the testing.
Handle nil autorequire results
With Puppet you can write:
Class['A'] ~> Class['B'] ~> Class['C']
This implies Class['A'] ~> Class['C'] and rspec-puppet actually will
tell you that chaining is there, but it doesn't actually happen. This
was reported in rodjek/rspec-puppet#821.
In this particular case it means that if DB seeding doesn't happen then
the apipie caches indexes aren't refreshed. By chaining it to db:migrate
there's a much bigger chance it actually happens.
Normally apipie:cache:index needs to run after a package is updated so
ideally this would actually be done in packaging, but this is the
workaround we've been using for a long time.
This allows you to check the return type of functions, like this
example:
```
is_expected.to run.with_params('mymod/template.epp', { 'foo' => 'bar' }).and_return(kind_of String)
```
Add the ability to use `kind_of` matchers
(maint) - Release prep v2.12.0
(GH-CAT-98) - Adding CODEOWNERS file
|
Please continue the discussion in puppetlabs#29 |
(MAINT) Merging old master in to main
Update README.md to include sensitive function
This is a minimal reproducer that's essentially A ~> B ~> C. The that_subscribes_to matcher shows that this is equal to A ~> C but in practice Puppet doesn't work that way. The service is not restarted if the file is modified. I don't know what is the expected behavior here, but it does mean that today it's not possible to test for real world behavior.
This is a minimal reproducer that's essentially A ~> B ~> C. The that_subscribes_to matcher shows that this is equal to A ~> C but in practice Puppet doesn't work that way. The service is not restarted if the file is modified.
I don't know what is the expected behavior here, but it does mean that today it's not possible to test for real world behavior.
I've submitted this as a PR since it's the easiest way to submit code and show CI results for it.