Issue #13595 has been updated by Chris Price. Due date set to 04/11/2012 Category set to testing Status changed from Unreviewed to Accepted Assignee set to Chris Price Priority changed from Normal to Urgent Target version set to 2.7.x
So, here is a straw-man proposal... feedback / suggestions / corrections much appreciated: 1. Revert my changes to various spec_helper classes (puppet 2.7.x, puppet master, stdlib, grayskull, and Eric's change). 2. Create a new class as part of puppet core: Puppet::Util::Test::Setup, or something to that affect. (Name suggestions particularly welcome.) Give it two methods: setup() and teardown(), which would be considered the public API for interacting with puppet during tests. This would be defined in 2.7.x and master; implementation details would be irrelevant to the outside world. 3. Use the puppetspec_helper project that Jeff mentioned to wrap this: it would need to have a single hack for the time being, which would basically be "if the class Puppet::Util::Test::Setup exists, call its methods, otherwise fallback to the old behavior". 4. Fix spec helpers in various external projects (stdlib, grayskull, et al.) to use puppetspec_helper rather than attempting to interact with puppet's setup/teardown directly; this prevents external projects from having to include a copy of the hack described in #3. The only downside that I see with this is that the jenkins jobs would need to be modified to pull down puppetspec_helper as part of their builds... and that *seems* palatable to me. Am I missing anything? Anyone else have any other concerns / suggestions? -------------------------------------------------------------------- Here are a few facts that the proposal above is based on: 1. We can't *entirely* revert the changes that I made to the spec_helpers and go back to the "old way", because the "old way" is not compatible with master--and can't be. There were some changes that were necessary to complete some roadmap goals with Telly that simply aren't compatible with the way the old spec_helpers were working. 2. It seems logical to me that external projects should *not* be responsible for managing puppet's state during test setup / teardown, so introducing new API for this seems necessary, and achieving 100% backward compatibility without modifying spec_helpers in external projects is unavoidable. 3. In the long run, separation of concerns between a) implementation details of puppet state management for testing, b) requests for this state management by external projects, and c) implementation details of bridging the gap between "a" and "b" seems desirable. ---------------------------------------- Bug #13595: initialize_everything_for_tests couples modules to specific Puppet versions https://projects.puppetlabs.com/issues/13595#change-59573 Author: Eric Shamow Status: Accepted Priority: Urgent Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: Branch: Ran into this while attempting to run spec tests on the puppetlabs-ntp module from Git: Failure/Error: Unable to find matching line from backtrace NoMethodError: undefined method `initialize_everything_for_tests' for #<Puppet::Util::Settings:0xb71fb30c> It turns out that :initialize_everything_for_tests was recently added to Puppet itself: https://github.com/puppetlabs/puppet/commit/56c55d54474d97958f0f21e715237cf3f2117668 There are two problems here: 1) We have no current documentation or method of knowing which version of Puppet is required for a particular module. We tie to specific module versions but not to Puppet itself - anyone trying to test the latest puppetlabs-ntp against the most recently cut version of Puppet or PE will fail. 2) We should be iterating on modules much more quickly than we are on core, but this means that modules need to be slightly more backward-compatible - we can't rely on the "latest and greatest" stuff in master or 2.7.x if modules are going to be updated frequently. It might make more sense to move this type of function out to stdlib. Commenting out the lines calling this function in the spec_helper.rb make the problem go away, but I suspect we're going to run into a lot more of these if we don't figure out an approach to it. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
