这似乎是一个琐碎的问题，但实际上并非如此。我正在使用puppet 3.7将项目中的工件部署和配置到各种环境。 Puppet 5.5升级已在路线图上，但目前尚无ETA。
我要自动化的一件事是对基础数据库的增量更改。它不是SQL，所以标准工具毫无疑问。这些更改将以特殊模块中包含的Shell脚本的形式出现，也将作为工件进行部署。对于每个发行版，我们都希望有一个文件，其内容将列出要在此发行版范围内执行的Shell脚本。例如，如果在1.2版中我们实现了JIRA-123，JIRA-124和JIRA-125，则我想执行JIRA-123.sh，JIRA-124.sh和JIRA-125.sh脚本，但没有其他脚本仍将包含在先前版本中的模块中。
因此，我发布的“控制”文件将被称为jiras.1.2.csv之类的内容，并且一行如下所示：
JIRA-123,JIRA-124,JIRA-125
这里的木偶任务似乎微不足道-读取此文件的内容，分割为“，”字符，然后继续为每个jiras构建exec任务。问题是应该帮助我完成操作的人偶功能
file("/somewhere/in/the/filesystem/jiras.1.2.csv")
在构建人偶目录时执行，而不是在应用目录时执行。但是，由于此文件是发行版有效负载的一部分，因此尚不存在。它将从发行版的tar.gz软件包中的nexus下载并在以后解压缩。我有一个锚点，可以用来同步exec任务，但是我可以将文件内容的读取附加到该锚点上吗？
也许我没有正确解决问题？我当时在考虑可以构成带有增量数据库升级的实施前和实施后任务的模块，以便每个发行版都有一个与版本名称匹配的子目录，但是随后我需要列出该子目录的内容以进行构建我的exec任务，至少在我有限的木偶知识上，也不能推迟到特定的锚点为止。
---在评论之一后编辑---
问题在于，升级到puppet 5.x超出了我的控制范围-这是另一个团队在一个大型组织中处理这些内容，因此我对此没有任何影响，并且在可预见的将来我坚持使用3.7。 / p>
关于我要做什么-对于我们开发和发布的许多不同的软件包，我想创建三个新软件包：实施前，实施后和检查。第一个将包含在实际软件包中发布新代码之前执行的所有任务。这通常是备份数据库之类的事情。实施后将处理在部署新代码后需要解决的问题-示例操作将是去修改旧数据，因为例如，我们已经更改了表中的列类型。检查只是为了确保版本100％正确实施而执行的验证-例如，运行选择查询并对列中我们刚刚更改过的数据类型进行断言。如今，所有这些都是令人讨厌的手动操作，由不希望发布的人员执行。然而，最重要的是，按照定义，这些都是容易出错的。
采用的方法是，对于每个JIRA票证的发行版，负责的开发人员将必须决定需要什么步骤（如果有）来发布其工作，并编写脚本。木偶应该统筹所有这些工作的执行。