Question

我有一个旧的单一食谱回购用于创建Vagrant的完整开发环境。我想＆＃34;重构＆＃34;根据最佳做法。我想分割大型烹饪书，制作适当的社区食谱包装食谱，并添加可由Testkitchen运行的InSpec测试，以便检查所有内容是否按预期安装。

我决定从头开始，看看通过执行chef generate app some_name将创建 skeleton 。此命令生成以下文件集：

.
|-- .gitignore
|-- .kitchen.yml     <----------
|-- README.md
|-- cookbooks
|   `-- some_name
|       |-- Berksfile
|       |-- chefignore
|       |-- metadata.rb
|       |-- recipes
|       |   `-- default.rb
|       `-- spec
|           |-- spec_helper.rb
|           `-- unit
|               `-- recipes
|                   `-- default_spec.rb
`-- test
    `-- smoke
        `-- default
            `-- default_test.rb

我注意到在根中创建了.kitchen.yml。从现在开始建议为每个食谱创建单个VCS repo，在根目录中.kitchen.yml看起来有点奇怪。但另一方面，保持VM配置以便在单个根文件中测试我的所有cookbook及其测试套件是个好主意。

然后我决定检查我是否能够从根.kitchen.yml运行所有项目的烹饪书的测试。我制作了一个简单的包装器手册，用于安装Java，并在cookbook的depends 'java'中使用metadata.rb并准备了根.kitchen.yml。

我从根目录运行kitchen test时面临的问题是，在执行厨房测试时，社区食谱java未得到解决。我尝试将Barksfile添加到cookbook目录中，但它没有帮助（仍然是未知的java依赖项）。看起来像Kitchen只适用于相对于.kitchen.yml的Berksfile。然后我尝试在项目根目录中添加Berksfile，当然，它不起作用，因为它还会在根目录中搜索metadata.rb。

所以看起来对项目根目录中的所有cookbook都有一个.kitchen.yml不是一个好主意。为什么它会产生呢？我也不喜欢我必须在每个cookbook的目录中编写几乎相同的.kitchen.yml，但看起来如果想要从metadata.rb解析依赖关系，我别无选择。

如果您还可以建议我使用包装器/角色烹饪书+测试的最佳实践的一个很好的示例repo，那将是很好的。我的项目很简单：它只是创建一些用户，准备环境并安装大量服务，主要使用包装的社区烹饪书。我希望将它保存在单个回购中并使用Kitchen + InSpec进行测试

Answer 1

app是manyrepo和monorepo设计的混合体，因此在这种结构中，您可以将所有本地烹饪书保存在单个回购中，并根据需要提取外部内容。 root kitchen.yml的想法是有一个地方为整个应用程序做顶级测试。通常这意味着最近测试政策而不是烹饪书，有关这方面的例子，请参阅https://github.com/poise/yolover-example。

至于食谱解决问题，如果不使用策略，你可能想要一个根Berksfile，尽管它可能只是：

source 'https://supermarket.chef.io/'
source chef_repo: '.'
cookbook 'whatever'

这种app风格有点像实验，可能需要稍作修改/更新。

.kitchen.yml文件在由＆＃39; chef生成应用程序生成的项目根目录中的目的是什么？

1 个答案: