I'd be happy to see a PR against puppet-module-skeleton (https://github.com/garethr/puppet-module-skeleton) for how you envisage testing against puppet-agent to work on (on Travis in this case). That might be a good way of getting a few people from the module community to comment too.
Ditto a PR regarding how the standard acceptance tests in puppet-module-skeleton would use the puppet-agent package/facter 3. One of the issues I see at present is that no puppet-agent package exists for OSX I believe, so lots of people who currently run spec tests locally won't be able to use the puppet-agent builds at present? Gareth On 15 May 2015 at 23:28, Kylo Ginsberg <[email protected]> wrote: > In the next few weeks we’ll be releasing facter 3, a native (compiled C++11) > implementation of facter. Note that the only packages containing facter 3 > will be the puppet-agent packages (e.g. there will be no facter 3 gems). > > > This change may have some workflow implications for module developers, and > we’d love to get some feedback on that, ideas for improvements, etc. > > > Starting with spec tests: no change *needed* but a small caveat. > Specifically, a module can continue to test against gems using its Gemfile, > including using the latest puppet 4 and facter 2 gems. The caveat is that > those spec tests will then *not* be running against facter 3. Facter 3 > supports the facter 2 ruby api for custom facts, so that should “just work” > (and we don’t know of any issues where it doesn’t) but at the same there is > some risk there. > > > However, fear not! You can spec test against facter 3 (or more generally > against puppet-agent) like so: > > install the desired puppet-agent build > > comment out the puppet and facter lines from your Gemfile > > profit! > > > On a related note: some such puppet-agent based workflow for specs may be > the long-term direction we want to take module spec testing, so that we’re > testing against the curated combination of puppet/facter/ruby/etc that a > puppet-agent build represents, as opposed to the larger combinatorial matrix > (e.g. X puppet versions vs Y facter versions vs Z ruby versions) that many > spec tests use today. > > > Moving on to module acceptance tests: here I’d more proactively encourage > module testing to move to using puppet-agent packages for acceptance tests. > This will be a benefit both for the facter 3 issue at hand, but more > generally (as mentioned above) to ensure that acceptance tests are run > against the puppet/facter/ruby/etc combinations that PL itself tests > against. > > > Hope that all makes some sense. Please chime in with any comments. > > > Thanks, > > Kylo > > -- > Kylo Ginsberg | [email protected] | irc: kylo | twitter: @kylog > > PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9. > Register now to take advantage of the Early Adopter discount —save $349! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CALsUZFHbyrx28s0eCcrbP_NaeDBK5UGp_DJPAP5GAbUfriuHDA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Gareth Rushgrove @garethr devopsweekly.com morethanseven.net garethrushgrove.com -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAFi_6yLV-5Ps9Mm0zDKqJpqLN2KHtsDizvm8Q7b3oFc9jKRksg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
