如何在任何组织上建立私人CircleCI球体

HackerNews什么值得看
139 阅读5分钟

使用CircleCI的orbs是一个跨项目共享CI/CD配置的好方法。公有bs对广泛采用很有帮助，但私有bs对需要以安全、非公开的方式分享共同的内部配置的组织很有帮助。私有轨道只在发布它们的组织内工作。

在这篇文章中，你将了解私人轨道和如何为你自己的组织使用它们。我们将使用我建立的样本轨道，它包含一个命令和一个工作，让你使用cURL在其他项目中触发CircleCI管道。你可以在这个资源库中找到这个项目的源代码。

前提条件

本文假设：

  • 具有CircleCI的工作知识
  • 了解管道的工作原理
  • 在您的机器上安装并配置了CircleCI CLI
  • 你正在使用GitHub上的项目组织或你的个人组织

私人仓库的使用情况

像一般的组织一样，私有组织对于分享多个项目共同的步骤和任务很有用。

许多组织都有自己的框架和内部工具，在许多团队中使用。通过私有仓库，他们可以轻松地分享这些工具，而不需要向更广泛的世界开放。私有轨道的一些用例包括部署到你专有的Kubernetes集群或其他基础设施，处理自定义硬件，一直到日志或普通管理任务。

初始设置

我们将使用CircleCI CLI来完成这项任务。通过CLI，你将创建一个新的轨道，并在CircleCI注册，以便它可以被其他CircleCI管道所引用。 CLI允许你发布你的球体的新版本。

创建一个空的git仓库并注意其路径。我在我的zmarkan-demos 组织下创建了我的，并命名为api-requester-orb-sample ，所以路径是：git@github.com:zmarkan-demos/api-requester-orb-sample.git 。

接下来，用CLI的circleci orb init 命令创建实际的兽皮，输入一个你希望兽皮源头所在的本地路径。这个目录必须是新的；不要使用已经存在的目录。在我的例子中，这就是。

circleci orb init ~/github/api-requester-orb-sample --private

公共和私人轨道之间的主要区别是末尾的--private 标志。

CLI要求你要么遵循指导性的设置，这就是我所做的，要么自己做。我建议使用自动流程，因为它将在目录中设置所有的空轨道模板，以及将其链接到你的仓库，为你的轨道创建一个命名空间，并为新的轨道创建一个CircleCI项目，只要确保从你之前创建的仓库中复制git URL。

最后，你需要将本地代码推送到远程版本库中 --

cd ~/github/api-requester-orb-sample
git push origin master

注意：所有的球体都存在于你的组织内的命名空间。这对于你已经注册的任何运行器代理都是一样的。

你也可以在你的组织设置中查看你的新的私有轨道，在type 部分中，它们被清楚地标记为私有。

List of orbs in the UI

开发一个球体

球体的开发过程取决于你是选择自动引导的过程还是遵循自己的过程。和设置部分一样，CircleCI的文档涵盖了两种情况。

如果你遵循快速设置的路线，那么CLI将为你生成整个项目的模板。它有一个命令、工作、执行器和测试的样本。

Orb project view

你可以删除任何你不需要的orb部分。在我的例子中，我删除了脚本和执行器，保留了命令和工作。Orb只是一个CircleCI配置脚本的集合，当你运行一个管道时，这些脚本会被解析和捆绑。

我们创建了2个脚本。

  • 一个commands/trigger-pipeline.yml 命令
  • 一个jobs/trigger-circleci-pipeline.yml 工作

作业包装了命令并在基本的Docker执行器中执行。

使用 trigger-pipeline 命令

trigger-pipeline 命令有4个参数，和一个单一的步骤，如这个代码样本中所示。

description: >
  This command triggers CircleCI pipeline specified.
  The job execution environment must have cURL utility available

parameters:
  repo-name:
    type: string
    description: "Repo name to trigger pipeline for"

  branch-name:
    type: string
    default: main
    description: "Branch name to trigger"

  trigger-params-json:
    type: string
    default: "{}"
    description: Pipeline trigger parameters in JSON format

  circle-token-env-var:
    type: env_var_name
    default: CIRCLE_TOKEN
    description: Environment variable containing your CircleCI API Key. Default is $CIRCLECI_API_KEY

steps:
  - run:
      name: Run cURL request
      command: |
        curl --request POST \
            --url "https://circleci.com/api/v2/project/gh/${CIRCLE_PROJECT_USERNAME}/<< parameters.repo-name >>/pipeline" \
            --header "Circle-Token: ${<< parameters.circle-token-env-var >>}" \
            --header "content-type: application/json" \
            --data '{"branch":"<< parameters.branch-name >>","parameters":<< parameters.trigger-params-json >>}"'

与完整的CircleCI管道配置不同，这个不需要一个version stanza。由于只有一个命令源，它也没有jobs 或workflows 。所有4个参数也都是针对这个命令的，与完整的CircleCI配置中的管道参数不同。

使用trigger-circleci-pipeline作业

编写一个消耗我们刚刚创建的命令的作业是很简单的。在同一个orb中，你可以使用该命令，就像你在配置中定义的本地命令一样。在我们的例子中，jobs/trigger-circleci-pipeline.yml ，它看起来像这样。

description: >
  Job that trigger CircleCI pipeline in another project with the payload specified

docker:
  - image: cimg/base:2021.12

parameters:
  repo-name:
    type: string
    description: "Repo name to trigger pipeline for"
  branch-name:
    type: string
    default: main
    description: "Branch name to trigger"

  trigger-params-json:
    type: string
    default: "{}"
    description: Pipeline trigger parameters in JSON format

  circle-token-env-var:
    type: env_var_name
    default: CIRCLE_TOKEN
    description: Environment variable containing your CircleCI API Key. Default is $CIRCLECI_API_KEY

steps:
  - trigger-pipeline:
      repo-name: << parameters.repo-name >>
      branch-name: << parameters.branch-name >>
      trigger-params-json: << parameters.trigger-params-json >>
      circle-token-env-var: << parameters.circle-token-env-var >>

这个命令有参数，和CircleCI中的其他工作一样，我们需要执行者：在我们的例子中是docker 。steps 节段包含一个单一的步骤，调用我们之前的trigger-pipeline 命令，以及我们设置的任何参数。

测试和部署球体

为了构建、测试和部署我们的轨道，轨道模板项目使用CircleCI本身。在.circleci/config.yml 中的配置中，大多数东西都是为你预制的。你所需要做的就是为它编写测试。默认情况下，它包含一个名为integration-test-1 的工作，你可以修改它来使用你自己的轨道。这里有一个调用trigger-pipeline 命令的片段。

jobs:
  integration-test-1:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - api-requester-orb-sample/trigger-pipeline:
          repo-name: pinging-me-softly
          branch-name: main
          trigger-params-json: '{"image-name": "cimg/base:2021.12"}'

要发布一个发布版本，你需要。

  • 从默认的alpha 分支改成master 或main 分支
  • 在提交中包含一个[semver:patch|minor|major] 的信息

总结

在这篇文章中，你已经了解了如何为CircleCI建立私有仓库，现在所有CircleCI客户都可以使用。私人轨道允许你在多个项目中共享CI/CD管道配置。这些私有的轨道可以被你的组织中的任何团队成员使用，而没有暴露你的配置给公众的风险。

整个过程与发布公共轨道的过程几乎相同。只要在circleci orb init 命令中添加--private 标志即可。

avatar
文章
阅读
粉丝