什么是CircleCi管道？它们可以用来触发带有参数的作业吗？ [英] What are CircleCi pipelines? Can they be used to trigger job with parameters?
问题描述
文档散布开来，如何在圆ci语言中使用管道概念有点困难？还有，管道和管道变量的意义是什么？
Documentation is spread out and it's a bit hard grasp how to make use of the pipeline concept in circle ci language? Also what's the point of pipelines and pipeline variables?
以下文档很有用，但远不足以让我弄清楚它们的实际工作原理：
The following docs were useful but were far from enough for me to figure out how they actually work:
- https://circleci.com /docs/2.0/pipelines
- https ：//circleci.com/docs/2.0/build-processing （启用管道）
- https://circleci.com/docs/2.0/pipeline-variables/#conditional-workflows （管道变量和条件工作流）
- https://circleci.com/docs / api / v2 /＃circleci-api-pipeline （管道API文档）
- https://circleci.com/docs/2.0/pipelines
- https://circleci.com/docs/2.0/build-processing (Enabling pipelines)
- https://circleci.com/docs/2.0/pipeline-variables/#conditional-workflows (Pipeline variables and conditional workflows)
- https://circleci.com/docs/api/v2/#circleci-api-pipeline (pipeline API docs)
推荐答案
TLDR应答er;
管道本质上是触发器-触发特定回购/
pipelines in circle ci are essentially triggers - triggering all workflows for a specific repo/branch/tag, including when circleci auto-triggers from a push/merge etc.
管道变量显然是需要在config.yml中声明和默认值的变量。显然只有通过2.0 API触发管道时才能设置它们的值。
pipeline variables are apparently variables that require declaration in config.yml and default values. Their values can apparently only be set when triggering a "pipeline" via the 2.0 API.
通过2.0 API触发的示例[github]：（注意：需要个人[不是项目]令牌）
Example trigger via 2.0 API [github]: (NOTE: Requires personal [not project] token)
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
长答案
如果您和我一样，可能会想到 workflow 。因此，剩下的问题是圆ci对管道意味着什么，经过一番尝试触发它并查看了文档的不同部分之后，我的结论是它可能应该被称为触发或工作流执行之类的东西。它实质上描述了给定分支/标记中所有工作流的触发，包括何时通过推送/合并自动触发该触发。
If you're anything like me, you might think of the word pipeline in the contect of CI as a hierarchy of jobs with dependencies between them and the ability to pass data from one step to the next. This feature exists in circle ci and is quite powerful (except that passing data is kind of awkward) but it's called workflow. Thus leaving the question of what circle ci mean with "pipeline", after some playing around with triggering it and looking at different parts of the docs, my conclusion is it should probably have been called "trigger" or "workflow execution" or something. It essentially describes the triggering of all workflows in a given branch/tag, including when that trigger is automatic through push/merge.
您不能使用管道来触发带有参数的作业，甚至根本无法触发作业，除非您首先将每个这样的作业包装在管道中并设置
You can't use a pipeline to trigger a job with parameters, or even trigger a job at all, not unless you first wrap each such job in a pipeline and set up a conditional scheme to not run other workflows.
为什么还要去那里？
老实说，我仍然不确定是否值得，但是基本上以下因素驱使我们：
I'm still not sure it's worth it to be honest, but basically the following drives us:
- 不要老了技术（不久将被丢弃）
- Orbs-一种仅适用于2.1配置的DRY管道的不错方法
问题吗？
用例1：基本上，我们有一项工作需要在3种不同的部署之后运行仓库，而不是在3个地方复制粘贴和维护代码，我们将作业放在第4个仓库中，并使用circleci API 1.1，并使用来自不同仓库的输入参数触发了该作业。在2.0 circleci配置中效果很好。在ci圈引入了回归以不再支持带参数的作业触发之后，在2.1配置中也无法实现。
Use case 1: Essentially we have a job that needs to run after deployments in 3 different repos and instead of copy-pasting and maintaining the code in 3 places, we put the job in a 4th repo and using circleci API 1.1, triggered it with input parameters from different repos. Works great in 2.0 circleci config. It's also impossible to achieve in 2.1 config after circle ci introduced the regression to no longer support job triggering with parameters.
用例2：在某些其他情况下，通过参数触发是很有用的，例如：正在进行的工作需要2个小时，而您不想等待进行测试在您的管道中。
Use case 2: In some other cases it's useful to trigger via parameters if say: a proceeding job takes 2 hours and you don't want to wait to test out something in your pipeline.
用例3：作业2失败，您需要先对其进行修复，然后再使用作业1的输出手动重新运行它。
Use case 3: Job 2 fails and you need to fix it before manually rerunning it with the output from job 1.
为简单起见，我们来看一个2个工作流程：
For simplicity lets look at a 2 job workflow:
+-------+ +-------+
| Job 1 | -> | Job 2 |
+-------+ +-------+
并且我们希望能够：
- 将变量从作业1传递到作业2
- 通过API执行作业2，将参数传递给作业
在circleci API 1.1中，将参数传递给作业很简单（通过API），它们会自动转换为环境变量。简单。
In circleci API 1.1 it's a simple matter of passing the parameters to the job (via API) and they are automatically transformed to Environment variables. Simple.
启用管道并在2.1配置中似乎并不是实现此目的的一种优雅方法。尽管由于存在球并在1个repo中保持完整的工作流而有所缓解（至少用例1）。但是，使用2.1管道有一种肿而骇人的方法，具体取决于（下面的POC示例）：
With "pipelines" enabled and in 2.1 config there doesn't seem to be an elegant way of achieving this. Although this is somewhat alleviated by the existence of orbs and keeping full workflow in 1 repo (at least use case 1). There is however a bloated and hacky way of doing it with 2.1 pipelines which comes down to (POC example below):
- 确保存在管道允许所有正常工作流都无法运行的参数。
- 添加管道参数以按需触发作业2
- 添加管道参数您需要传递给作业2的实际参数。
- 创建一个作业3，该作业采用管道参数并将其作为env vars传递给作业2。
- 创建一个工作流，该工作流在设置按需变量时先运行作业3，然后运行作业2。
- Ensure there's a pipeline parameter that allows all "normal" workflows to not run.
- Add a pipeline parameter for on-demand triggering of job 2
- Add pipeline parameters for the actual parameters you need to pass to job 2.
- Create a job 3 that takes pipeline parameters and passes them to job 2 as env vars.
- Create a workflow that runs job 3 and then job 2 when the on-demand variable is set
尴尬？哦是的我只能猜测circle ci在引入管道变量时会想到其他用例，因为这不是很方便。
Awkward? Oh yes. I can only guess that circle ci had some other use case in mind for their introduction of pipeline variables because this is just not very convenient.
结论
我仍然无法真正弄清您的状态应该使用管道变量。也许将来官方文档会对此有更清晰的说明。
I still can't really figure out how you are "supposed to" use pipeline variables. Maybe official docs will have more clarity on this in the future.
我真的看到了对管道变量的需求，它们可能非常强大，但其局限性导致一些尴尬，至少对于我们的用例。我发现以下限制最令人讨厌：
I really see the need for pipeline variables and they could be quite powerful but their limitations lead to some awkwardness, at least for our use cases. I find the following limitations the most annoying:
- （我认为）无法在作业1中设置管道变量，从作业中访问它2。
- （我认为）无法在作业定义中设置管道变量。
- 变量必须预先定义。
- 无法选择性地仅运行一个工作流
- 无法选择性地仅运行一个工作
- No way (I think) to set a pipeline variable in job 1, accessing it from job 2.
- No way (I think) to set a pipeline variable in job definition.
- Variables must be predefined.
- No way to selectively just run one workflow
- No way to selectively just run one job
使用job1的输出或按需将参数发送到自定义管道，自定义工作流和临时job3的运行job2的config.yml的工作示例POC：
Working example POC of config.yml for running job2 both using output from job1 or on-demand with parameters sent to custom pipeline, custom workflow and interim job3:
version: 2.1
# Pipeline parameters
parameters:
workflow_ondemand:
type: boolean
default: false
workflow_job2_ondemand:
type: boolean
default: false
workflow_job2_param1_version:
type: string
default: "invalid version"
workflows:
version: 2
normal-workflow:
unless: << pipeline.parameters.workflow_ondemand >>
jobs:
- job1
- job2:
requires: [job1]
workflow-job2-ondemand:
when: << pipeline.parameters.workflow_job2_ondemand >>
jobs:
- job3
- job2:
requires: [job3]
# Trigger with:
#
# curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
# "branch": "feat",
# "parameters": {
# "workflow_ondemand": true,
# "workflow_job2_ondemand": true,
# "workflow_job2_param1_version": "version1"
# }
# }' https://circleci.com/api/v2/project/gh/<org>/<repo>/pipeline
jobs:
job1:
docker:
- image: circleci/node:latest
steps:
- run:
name: Fake build and generate random version number
command: |
echo export VERSION=$((1 + RANDOM % 100)) >> /tmp/.env
source /tmp/.env
echo "Version in job1: ${VERSION}"
- persist_to_workspace:
root: /tmp/
paths: ['.env']
job2:
docker:
- image: circleci/node:latest
steps:
- attach_workspace:
at: /tmp
- run:
name: "Load and print version from previous step"
command: |
source /tmp/.env
echo "Version in job2: ${VERSION}"
job3:
docker:
- image: circleci/node:latest
environment:
VERSION: << pipeline.parameters.workflow_job2_param1_version >>
steps:
- run:
name: "Save parameter value to .env"
command: |
echo export VERSION=${VERSION} >> /tmp/.env
echo "Version in job3: ${VERSION}"
- persist_to_workspace:
root: /tmp/
paths: ['.env']
这篇关于什么是CircleCi管道？它们可以用来触发带有参数的作业吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
