什么是CircleCi管道？可以使用它们来触发带有参数的作业吗？

问题描述 投票：0回答：1

文档散布开来，如何在圆环ci语言中利用pipeline概念有点困难？还有管道和管道变量的意义是什么？

以下文档很有用，但远远不足以让我了解它们的实际工作方式：

continuous-integration pipeline circleci
1个回答
0
投票

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对“管道”意味着什么，在经过一些触发并看了文档的不同部分之后，我的结论是它可能应该被称为“触发”或“工作流执行”之类的东西。它实质上描述了给定分支/标记中所有工作流的触发，包括何时通过推送/合并自动触发该触发。

您不能使用管道来触发带有参数的作业，除非您首先将每个这样的作业包装在管道中并设置一个条件方案以不运行其他工作流程。否则>>

为什么还要去那里？

老实说，我仍然不确定是否值得，但是基本上以下因素驱使我们：

  • 不要停留在旧技术上（不久将被丢弃）
  • Orbs-一种仅适用于2.1配置的DRY管道的不错方法

    • 问题？

[用例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 |
+-------+      +-------+

而且我们希望能够：
  • 将变量从作业1传递到作业2
  • 通过API执行作业2，将参数传递给作业

    • 在circleci API 1.1中，只需将参数（通过API）传递给作业即可，然后它们会自动转换为环境变量。简单。

启用“管道”并在2.1配置中，似乎并不是实现此目的的一种优雅方法。尽管由于存在球并在1个repo中保持完整的工作流而有所缓解（至少在用例1中）。但是，使用2.1管道有一种a肿而笨拙的方法，它归结为（下面的POC示例）：

  • 确保有一个管道参数允许所有“正常”工作流都不会运行。
  • 添加管道参数以按需触发作业2
  • 为需要传递给作业2的实际参数添加管道参数。
  • [创建作业3，该作业需要管道参数并将它们作为env vars传递给作业2。
  • 设置了按需变量后，创建一个运行作业3然后运行作业2的工作流

    • 尴尬？哦是的我只能猜测circle ci在引入管道变量时会想到其他用例，因为这不是很方便。

结论

我仍然无法真正弄清如何“应该”使用管道变量。也许将来官方文档会对此有更清晰的说明。

我真的看到了对管道变量的需求，它们可能非常强大，但是它们的局限性导致了一些尴尬，至少对于我们的用例而言。我发现以下限制最令人讨厌：

  • （我认为无法在作业1中设置管道变量，可以从作业2中访问它。
  • （我认为）无法在作业定义中设置管道变量。
  • 变量必须预定义。
  • 无法选择性地仅运行一个工作流程
  • 没有办法选择性地只执行一项工作

    • [config.yml的工作示例POC，用于使用job1的输出或按需将参数发送到自定义管道，自定义工作流和临时job3来运行job2：

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']
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.