文档散布开来，如何在圆环ci语言中利用pipeline概念有点困难？还有管道和管道变量的意义是什么？
以下文档很有用，但远远不足以让我了解它们的实际工作方式：
TLDR答案;
ci圈中的[pipelines本质上是触发器-触发特定回购/分支/标签的所有工作流程，包括何时从推/合并中自动触发Circleci等]
管道变量显然是需要在config.yml中声明和默认值的变量。它们的值显然只能在通过2.0 API触发“管道”时进行设置。
通过2.0 API [github]的示例触发器：（注意：需要个人[非项目]令牌）
curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
"branch": "feat",
"parameters": {
"image-tag": "4.8.2"
}
}' https://circleci.com/api/v2/project/gh/<org>/<repo>/pipeline
长回答
[如果您像我一样，您可能会把CI的词pipeline视为作业的层次结构，它们之间具有依赖性，并且能够将数据从一个步骤传递到下一个步骤。此功能存在于ci圈中，功能非常强大（除了传递数据有点尴尬），但它被称为workflow。因此，剩下的问题是圆ci对“管道”意味着什么，在经过一些触发并看了文档的不同部分之后，我的结论是它可能应该被称为“触发”或“工作流执行”之类的东西。它实质上描述了给定分支/标记中所有工作流的触发，包括何时通过推送/合并自动触发该触发。
您不能使用管道来触发带有参数的作业，除非您首先将每个这样的作业包装在管道中并设置一个条件方案以不运行其他工作流程。否则>>
为什么还要去那里？
老实说，我仍然不确定是否值得，但是基本上以下因素驱使我们：
问题？
[用例1：本质上，我们有一个工作需要在3个不同的存储库中进行部署之后运行，而不是在3个地方复制粘贴和维护代码，我们将该工作放在第4个存储库中并使用circleci API 1.1，它具有来自不同存储库的输入参数。在2.0 circleci配置中效果很好。在Circ ci引入了回归以不再支持带参数的作业触发之后，也无法在2.1配置中实现。
用例2：在某些其他情况下，如果说：通过一个参数触发是很有用的：一项正在进行的工作需要2个小时，而您不想等待测试管道中的某些内容。
用例3：作业2失败，您需要对其进行修复，然后再使用作业1的输出手动重新运行它。
为简单起见，我们看一下2个工作流程：
+-------+ +-------+ | Job 1 | -> | Job 2 | +-------+ +-------+而且我们希望能够：
在circleci API 1.1中，只需将参数（通过API）传递给作业即可，然后它们会自动转换为环境变量。简单。
启用“管道”并在2.1配置中，似乎并不是实现此目的的一种优雅方法。尽管由于存在球并在1个repo中保持完整的工作流而有所缓解（至少在用例1中）。但是，使用2.1管道有一种丑陋，肿且笨拙的方式，它可以归结为：
尴尬？哦是的我只能猜测circle ci在引入管道变量时会想到其他用例，因为这不是很方便。
结论
我仍然无法真正弄清如何“应该”使用管道变量。也许将来官方文档会对此有更清晰的说明。
我真的看到了对管道变量的需求，它们可能非常强大，但是它们的局限性导致了一些尴尬，至少对于我们的用例而言。我发现以下限制最令人讨厌：