Issue #13595 has been updated by Jeff McCune.
Chris Price wrote: > 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? This seems totally reasonable and fine by me. The only two additional pieces of information I'd like it add are: 1. It's always bugged the crap out of me that irb -r puppet gives you something only semi-functional and does a LOT of initialization of the framework configuration for you. This irritation is dated about 18 to 24 months ago though. I believe dpittman may have improved this substantially since then so this may be a moot point. I mention this annoyance of mine because initializing the framework for testing is very similar to initializing the framework for other uses like interactive shells or other applications. It would be great if you keep an eye toward better ways to separate out loading the framework and initializing the framework to make the framework easier to work with. There are no action items on this point, it's just something I'd ask that you keep in mind since you'll be in this part of the code. The litmus test I use to determine if it's easy to work with is something like, "What are the number of steps after irb -r puppet I need to make to get Puppet into the state I want it in for my use case? The lower the number, the better." 2. Some rather prevalent documentation or communication on "The Standard Way" to initialize puppet for testing will be invaluable for the community. Putting it in the README_DEVELOPER will be a great first step, we can take it from there and bake it into puppet module generate or what not. I mention this not because I don't think you wouldn't already do this but rather because I just didn't see it mentioned in this straw man. ---------------------------------------- Bug #13595: initialize_everything_for_tests couples modules to specific Puppet versions https://projects.puppetlabs.com/issues/13595#change-59745 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.
