Actionplan stability about kitchenplan

[leftathome]

Versioning kitchenplan is a good idea. That way, if a massive pull request comes in that adds support for other platforms or dependency resolvers comes in, you have a way of letting existing users pin to their last comfortable version.

I'm struggling a bit with CI myself. Travis isn't an option for my fork, so the likely answer is going to be Jenkins, Vagrant and VMware Fusion (relying on Virtualbox may make testing OS X difficult - the VM it boots seems to be a bit wonky...).

One option might be to run Kitchenplan on a special nerfed/stubbed platform that essentially sources all the cookbooks and runs Chefspec on them. That should work fine in Travis, provided the cookbook maintainers write Chefspec tests.

[thomasmeeus]

I agree with everything above, except the wrapper cookbooks. I can't see why that's necessary. It may come in handy to combine several apache recipes into one recipe in Kitchenplan, but a complete wrapper cookbook seems overkill to me.

[roderik]

I want to limit the dependencies of the cookbooks. if we use the community cookbook x and have a recipes that depends on it + does some configuration, that recipe should be in a different cookbook

On 06 Feb 2014, at 08:55, Thomas Meeus [email protected] wrote:

I agree with everything above, except the wrapper cookbooks. I can't see why that's necessary. It may come in handy to combine several apache recipes into one recipe in Kitchenplan, but a complete wrapper cookbook seems overkill to me.

—
Reply to this email directly or view it on GitHub.

[roderik]

Lot has happened this weekend:

• current master is fully tagged for versions, this, in theory, should mean it will build forever. In practice, there is an issue with the current cask release, fixed though in the next version. That cannot be solved. The cleanup branch works on the "master" of the different chef- cookbooks.
• the homebrew cookbook can now install apps and casks from an attribute list. This means that i could remove all recipes in applications that do not "add" some configuration. These apps are now in the config file, and allows for adding everything in cask and homebrew to be installed without adding new recipes.
• The same was done for node application.
• There was a bug that would lose attributes if used in two differen yml files. This was ffixed by a special deep_merge command from activesupport. Unfortunately, this only installs on ruby 1.9.3 and up, so this breaks Mountain Lion support. @thomasmeeus will try to fix this :)
• the debian support was dropped for now, reducing the cookbooks needed to a fraction it was before

Try it out and give me some feedback!

[roderik]

Ok ML support has been restored, some bugs fixed. So v2.0 released; https://github.com/kitchenplan/kitchenplan/releases/tag/v2.0