ktomk/pipelines

Bitbucket 流水线运行器

维护者

详细信息

github.com/ktomk/pipelines

主页

源代码

问题

安装次数: 16,888

依赖者: 0

建议者: 0

安全: 0

星星: 109

关注者: 7

分支: 11

开放问题: 11

0.0.70 2023-08-07 04:34 UTC

Requires

Requires (Dev)

Suggests

  • ext-yaml: Preferred YAML parser; highly recommended.

AGPL-3.0-or-later 8f61cda143cf6487cbde82c882a4d8c112f35445

  • Tom Klingenberg <ktomk.woop@github.com>

This package is auto-updated.

Last update: 2024-09-03 22:27:17 UTC

README

在任何地方运行 Bitbucket 流水线

CI Status Build Status Code Coverage Scrutinizer Code Quality

用 PHP 编写的命令行管道运行器。可在 Github 或 Packagist 上获取。

使用方法 | 环境 | 退出状态 | 详细信息 | 参考资料

使用方法

在项目或 (Git) 仓库中的任何位置，只要存在 Bitbucket 流水线文件

$ pipelines

从 bitbucket-pipelines.yml [BBPL] 运行管道命令。

忽略内存和时间限制。按 ctrl + c 退出。

忽略每个流水线的 100 个步骤限制（之前为 10）。

退出状态来自最后一个管道脚本命令，如果命令失败，则不会执行后续脚本命令和步骤。

如果没有默认流水线，则运行默认流水线。如果没有默认流水线，pipelines 会提示并退出非零状态。

要执行不同的流水线，请使用 --pipeline <id> 选项，其中 <id> 是通过 --list 选项列出的列表之一。还可以通过 --show 获取更多关于流水线的信息。Both --list 和 --show 输出并退出。

使用 --steps <steps> 指定要执行哪些步骤（以及顺序）。

如果下一个流水线步骤具有手动触发，pipelines 将停止执行，并在标准错误上输出一条简短消息，说明情况。可以通过 --no-manual 选项忽略手动触发。

使用 --trigger <ref> 以标签/分支或书签的形式运行流水线，其中 <ref> 是 tag:<name>、branch:<name>、bookmark:<name> 或 pr:<branch-name>[:<destination-branch>]。如果没有同名标签、分支、书签或拉取请求流水线，则会将名称与引用类型的模式进行比较，如果找到，则运行该流水线。

否则，如果没有默认流水线，则不会运行任何流水线，命令以非零状态退出。

可以同时使用 --pipeline 和 --trigger，--pipeline 会覆盖 --trigger 的流水线，但 --trigger 仍会影响容器环境变量。

要指定不同的文件，请使用 --basename <basename> 或 --file <path> 选项，并/或设置工作目录 --working-dir <path>，其中查找文件，除非通过 --file <path> 设置了绝对路径。

默认情况下，pipelines 在当前工作树上运行，该工作树被复制到容器中以隔离运行流水线与工作目录（隐式 --deploy copy）。

或者，可以使用 --deploy mount 将工作目录挂载到流水线容器中。

使用 --keep 标志在流水线完成后保留容器以进行进一步检查。默认情况下，所有容器都会被销毁。有时在开发过程中，仅在出错时保留容器是有趣的，--error-keep 标志就是为了这个。

在任何情况下，如果流水线再次运行并发现具有相同名称的现有容器（由流水线名称等生成），则会重用现有容器。这可以非常快速地重复使用，非常有用。

使用--docker-list管理剩余容器，显示所有流水线容器，使用--docker-kill终止正在运行的容器，使用--docker-clean删除停止的流水线容器。组合使用，例如，完全清理：

$ pipelines --docker-list --docker-kill --docker-clean

或者只运行以进行更低调的清理

$ pipelines --docker-zap

首先终止并删除所有流水线容器（不显示列表）。“zap”是流水线的“make clean”等效于--keep。

所有由pipelines运行的容器都贴有标签，便于维护。

使用--show验证你的bitbucket-pipelines.yml文件，它将突出显示找到的错误。

对于模式验证，使用--validate [<file>]。模式验证可能显示在执行流水线时不是问题（--show和/或--dry-run更好）的错误，但与Atlassian/Bitbucket提供的模式相验证（与上游相比，该模式更宽松，因为在已知提供更好实际体验的情况下）。例如，用于CI流水线中的检查或在使用预提交钩子或本地构建之前对文件进行lint检查。

使用--dry-run检查你的流水线，这将处理流水线但不执行任何操作。与-v（，--verbose）结合使用，以显示将要运行的命令的原始版本，这有助于更好地理解pipelines实际上是如何工作的。这里没有要隐藏的东西。

使用--no-run不运行流水线，这可以用于测试实用程序的选项。

流水线环境变量可以通过-e、--env和--env-file选项按名称或文件传递到或设置你的流水线。

环境变量也来自名为.env.dist和.env的点环境文件，并按此顺序处理环境选项之前。使用--no-dot-env-files防止自动加载，--no-dot-env-dot-dist仅用于.env.dist文件。

有关流水线环境变量的更多信息，请参阅下面的环境部分。

帮助

通过-h、--help可以查看流水线实用程序的完整选项和参数。

usage: pipelines [<options>] --version | -h | --help
       pipelines [<options>] [--working-dir <path>] [--file <path>]
                 [--basename <basename>] [--prefix <prefix>]
                 [--verbatim] [--[no-|error-]keep] [--no-run]
                 [(-e | --env) <variable>] [--env-file <path>]
                 [--no-dot-env-files] [--no-dot-env-dot-dist]
                 [--docker-client <package>] [--ssh]
                 [--user[=<name|uid>[:<group|gid>]]]
                 [--deploy mount | copy ] [--pipeline <id>]
                 [(--step | --steps) <steps>] [--no-manual]
                 [--trigger <ref>] [--no-cache]
       pipelines [<options>] --service <service>
       pipelines [<options>] --list | --show | --images
                 | --show-pipelines | --show-services
                 | --step-script[=(<id> | <step>[:<id>])]
                 | --validate[=<path>]
       pipelines [<options>] --docker-client-pkgs
       pipelines [<options>] [--docker-list] [--docker-kill]
                 [--docker-clean] [--docker-zap]

Generic options
    -h, --help            show usage and help information
    --version             show version information
    -v, --verbose         be more verbose, show more information and
                          commands to be executed
    --dry-run             do not execute commands, e.g. invoke docker or
                          run containers, with --verbose show the
                          commands that would have run w/o --dry-run
    -c <name>=<value>     pass a configuration parameter to the command

Pipeline runner options
    --basename <basename> set basename for pipelines file, defaults to
                          'bitbucket-pipelines.yml'
    --deploy mount|copy   how files from the working directory are
                          placed into the pipeline container:
                          copy     (default) working dir is copied into
                                 the container. stronger isolation as
                                 the pipeline scripts can change all
                                 files without side-effects in the
                                 working directory
                          mount    the working directory is mounted.
                                 fastest, no isolation
    --file <path>         path to the pipelines file, overrides looking
                          up the <basename> file from the current
                          working directory, use '-' to read from stdin
    --trigger <ref>       build trigger; <ref> can be either of:
                          tag:<name>, branch:<name>, bookmark:<name> or
                          pr:<branch-name>[:<destination-branch>]
                          determines the pipeline to run
    --pipeline <id>       run pipeline with <id>, use --list for a list
                          of all pipeline ids available. overrides
                          --trigger for the pipeline while keeping
                          environment from --trigger.
    --step, --steps <steps>
                          execute not all but this/these <steps>. all
                          duplicates and orderings allowed, <steps> are
                          a comma/space separated list of step and step
                          ranges, e.g. 1 2 3; 1-3; 1,2-3; 3-1 or -1,3-
                          and 1,1,3,3,2,2
    --no-manual           ignore manual steps, by default manual steps
                          stop the pipeline execution when not the first
                          step in invocation of a pipeline
    --verbatim            only give verbatim output of the pipeline, do
                          not display other information like which step
                          currently executes, which image is in use ...
    --working-dir <path>  run as if pipelines was started in <path>
    --no-run              do not run the pipeline
    --prefix <prefix>     use a different prefix for container names,
                          default is 'pipelines'
    --no-cache            disable step caches; docker always caches

File information options
    --images              list all images in file, in order of use, w/o
                          duplicate names and exit
    --list                list pipeline <id>s in file and exit
    --show                show information about pipelines in file and
                          exit
    --show-pipelines      same as --show but with old --show output
                          format without services and images / steps are
                          summarized - one line for each pipeline
    --show-services       show all defined services in use by pipeline
                          steps and exit
    --validate[=<path>]   schema-validate file, shows errors if any,
                          exits; can be used more than once, exit status
                          is non-zero on error
    --step-script[=(<id> | <step>[:<id>])]
                          write the step-script of pipeline <id> and
                          <step> to standard output and exit

Environment control options
    -e, --env <variable>  pass or set an environment <variable> for the
                          docker container, just like a docker run,
                          <variable> can be the name of a variable which
                          adds the variable to the container as export
                          or a variable definition with the name of the
                          variable, the equal sign "=" and the value,
                          e.g. --env NAME=<value>
    --env-file <path>     pass variables from environment file to the
                          docker container
    --no-dot-env-files    do not pass .env.dist and .env files as
                          environment files to docker
    --no-dot-env-dot-dist dot not pass .env.dist as environment file to
                          docker only

Keep options
    --keep                always keep docker containers
    --error-keep          keep docker containers if a step failed;
                          outputs non-zero exit status and the id of the
                          container kept and exit w/ container exec exit
                          status
    --no-keep             do not keep docker containers; default

Container runner options
    --ssh                 ssh agent forwarding: if $SSH_AUTH_SOCK is set
                          and accessible, mount SSH authentication
                          socket read only and set SSH_AUTH_SOCK in the
                          pipeline step container to the mount point.
    --user[=<name|uid>[:<group|gid>]]
                          run pipeline step container as current or
                          given <user>/<group>; overrides container
                          default <user> - often root, (better) run
                          rootless by default.

Service runner options
    --service <service>   runs <service> attached to the current shell
                          and waits until the service exits, exit status
                          is the one of the docker run service
                          container; for testing services, run in a
                          shell of its own or background

Docker service options
    --docker-client <package>
                          which docker client binary to use for the
                          pipeline service 'docker' defaults to the
                          'docker-19.03.1-linux-static-x86_64' package
    --docker-client-pkgs  list all docker client packages that ship with
                          pipelines and exit

Docker container maintenance options
      usage might leave containers on the system. either by interrupting
      a running pipeline step or by keeping the running containers
      (--keep, --error-keep)

      pipelines uses a <prefix> 'pipelines' by default, followed by '-'
      and a compound name based on step-number, step-name, pipeline id
      and image name for container names. the prefix can be set by the
      --prefix <prefix> option and argument.

      three options are built-in to monitor and interact with leftovers,
      if one or more of these are given, the following operations are
      executed in the order from top to down:
    --docker-list         list prefixed containers
    --docker-kill         kills prefixed containers
    --docker-clean        remove (non-running) containers with
                          pipelines prefix

      for ease of use:
    --docker-zap          kill and remove all prefixed containers at
                          once; no show/listing

Less common options
    --debug               flag for trouble-shooting (fatal) errors,
                          warnings, notices and strict warnings; useful
                          for trouble-shooting and bug-reports

使用场景

从预发布区域快速测试运行你的项目和流水线更改。由于流水线通常在远处执行，因此设置它们变得繁琐，在Bitbucket Pipelines文档 [BBPL-LOCAL-RUN]中提供的指南有一些提示，但并不涉及Bitbucket流水线运行器。

这就是pipelines命令介入的地方。

pipelines命令通过在本地开发机器上执行配置的任何流水线，弥合了本地开发和远程流水线执行之间的差距。只要本地可以访问Docker，就会解析bitbucket-pipelines.yml文件，并负责在选择的容器中执行所有步骤及其命令。

与Atlassian Bitbucket流水线服务相比，流水线YAML文件解析、容器创建和脚本执行尽可能接近。可以根据需要将环境变量传递到每个流水线。你甚至可以切换到如Github/Travis等不同的CI/CD服务，只需进行少量集成工作，从而促进你的灵活性和供应商独立性。

功能

功能包括

开发模式

像以前一样从你的工作树中创建流水线。假装在任意的分支、标签或书签（--trigger）上，即使在不同的存储库或没有任何存储库。

检查引用是否匹配管道或直接运行默认（默认）或特定的一个（--list，--pipeline）。使用不同的管道文件（--file）或通过更改工作目录（--working-dir <path>）来交换“仓库”。

如果管道步骤失败，可以使用--error-keep选项保留步骤容器以进行错误检查。此时会显示容器ID，这使得在容器内启动shell变得容易。

$ docker exec -it $ID /bin/sh

可以使用--keep始终保留容器以进行调试和手动测试管道，错误情况下也使用--error-keep。保留的容器无论是否使用--keep（，--error-keep）选项都会按名称重新使用。

可以使用--steps <steps>参数继续执行（失败的）步骤，<steps>选项可以是任何步骤编号或序列（1-3），多个步骤之间用逗号分隔（3-,1-2），甚至可以重复步骤或反转顺序（4,3,2,1）。

例如，如果第二个步骤失败，则可以使用--steps 2-继续执行以重新运行第二个和所有后续步骤（使用--steps 2或--step 2将只运行下一个步骤；进行逐步方法）。

之后，可以使用--docker-list|kill|clean来管理剩余内容，或使用--docker-zap进行清理。

调试选项值得期待；利用本地构建和管道容器。

容器隔离

每个步骤都有一个容器，就像在Bitbucket上一样。

文件在执行管道步骤脚本之前被复制到容器中，从而实现隔离（隐式--deploy copy）。

或者可以使用--deploy mount将文件挂载到容器中，这在Linux上通常更快，但工作树可能会被容器脚本更改，这可能导致不受欢迎的副作用。Docker在系统范围内运行，容器不隔离用户（例如，root是root）。

使用--deploy mount（并获得安全感）在rootless模式下使用Docker，在管道容器中处理的文件可以访问自己的用户账户（就像root自动映射到你的用户一样）。

管道集成

通过使用工件从管道中导出文件，这些工件在（隐式）--deploy copy模式下复制回工作树。工件文件始终由运行管道的用户创建。这也（几乎）完美地模拟了文件格式artifacts部分，其优点/缺点是您可能希望在管道步骤脚本中准备干净的构建，同时您可以保留管道的本地工件。这是多年来已被证明可以接受的权衡。

用脚本包装pipelines进行干净的检出，或等待未来的选项首先进行阶段设置（git-deployment功能）。在任何情况下，首先要控制您的构建。

准备离线使用

在飞机上？乘坐德国铁路？或者在偏远地区的雨天，网络中断？在国外编码？或者Bitbucket再次宕机？

在进入离线模式之前，了解离线工作你会喜欢的。

服务？检查！

本地管道运行器在您的本地盒子/系统上运行服务容器（即您的管道的主机）。这与在Bitbucket Pipelines中使用服务和数据库 [BBPL-SRV] 类似。

在任何管道步骤使用服务之前，可以使用--service选项测试服务定义，将设置管道中的服务变成一种新的体验。这是测试服务定义和了解消耗额外资源的好方法。

默认镜像

pipelines命令使用默认镜像，如Bitbucket Pipelines所做的那样("atlassian/default-image")。开箱即用，但请注意，其大小大约为1.4 GB。

流水线内部的流水线

作为一项特殊功能，pipelines默认会将docker socket挂载到每个容器中（在socket可用的系统上）。只要pipelines容器中有pipelines和Docker客户端，就可以从流水线启动流水线。只要流水线有docker服务（services: [docker]），pipelines就会负责/usr/bin/docker中的Docker客户端。

此功能与在Bitbucket Pipelines中运行Docker命令 [BBPL-DCK] 类似。

流水线内部的流水线功能非常适合pipelines本身进行项目构建的集成测试。结合--deploy mount，将原始工作目录从主机（再次）挂载。为了防止意外的递归调用而导致的无限循环，已实现了额外的保护措施。

环境

Pipelines模拟了“所有”Bitbucket Pipelines容器内环境变量 [BBPL-ENV]，也称为环境参数

  • BITBUCKET_BOOKMARK - 由--trigger条件设置
  • BITBUCKET_BUILD_NUMBER - 总设置为"0"
  • BITBUCKET_BRANCH - 由--trigger条件设置
  • BITBUCKET_CLONE_DIR - 总设置为容器中的部署点
  • BITBUCKET_COMMIT - 由于没有修订版会触发构建，因此始终设置为"0000000000000000000000000000000000000000"
  • BITBUCKET_REPO_OWNER - 从环境变量获取当前用户名，如果不可用则为"nobody"
  • BITBUCKET_REPO_SLUG - 项目目录的基名
  • BITBUCKET_TAG - 由--trigger条件设置
  • CI - 总设置为"true"

所有这些（但不包括BITBUCKET_CLONE_DIR）都可以在pipelines运行的环境中设置，并传递到容器环境中。示例

$ BITBUCKET_BUILD_NUMBER=123 pipelines # build no. 123

有关（Bitbucket）pipelines环境变量的更多信息，请参阅Pipelines环境变量使用参考。

此外，pipelines还设置了一些环境变量以供检查

  • PIPELINES_CONTAINER_NAME - 容器本身的名称
  • PIPELINES_ID - 当前运行的流水线的<id>
  • PIPELINES_IDS - 空格分隔的运行中的<id>的md5散列列表。用于检测流水线内部的递归，防止系统故障前的执行。
  • PIPELINES_PARENT_CONTAINER_NAME - 如果在流水线开始时已设置，则为容器名称（流水线内部的“pip”）。
  • PIPELINES_PIP_CONTAINER_NAME - 第一个（初始）流水线容器的名称。由流水线内部的流水线（“pip”）使用。
  • PIPELINES_PROJECT_PATH - 原始项目的路径，如同用于 --deploy 命令并带有 copy 或 mount 时，以便在管道内部进行 --deploy mount 操作，即使当前容器未挂载。挂载始终需要运行管道的系统的项目目录路径。如果没有现有的挂载（例如 --deploy copy），否则将无法识别。在管道内操作此参数会导致未定义行为，并可能影响系统安全。

这些环境变量由管道本身管理。其中一些可以注入，这可能导致未定义行为，并可能影响系统安全。

除了这些特殊用途的环境变量之外，任何其他环境变量都可以通过 -e、--env 和 --env-file 选项导入到或设置在容器中。它们的行为与 docker run 命令 中所述的完全一致 [DCK-RN]。

默认情况下，管道会自动使用每个项目支持的相同文件格式（如 docker）的环境变量 .env.dist 和 .env 文件，而不是为每次调用指定自定义环境参数。

退出状态

成功时的退出状态是 0（零）。

非零退出状态表示错误

  • 1：提供的参数（包括缺失的参数）导致错误。
  • 2：由于系统无法执行命令（例如，无法读取文件）而引起错误。
  • 127：在管道内部运行管道时检测到无限循环失败。

示例

找不到文件可能因为错误而导致退出状态 2（两个），因为文件未找到。然而，使用类似 --show 的开关时，退出状态可能是 1（一个），因为有错误显示该文件不存在（间接地），并且错误更突出地显示了该文件的管道。

详细信息

要求 | 用户测试 | 安装 | 已知错误 | 待办事项

要求

管道在具有 PHP 运行时的 POSIX 兼容系统上运行最佳。

由于它用于运行管道，因此本地需要可用的 Docker，作为 docker 命令。支持无根 Docker。

推荐使用较新的 PHP 版本，pipelines 命令需要 PHP 来运行。它应与 PHP 5.3.3+ 兼容。开发环境应为 PHP 7+，这对于未来的版本尤其建议。也支持 PHP 8+。

强烈建议安装 PHP YAML 扩展 [PHP-YAML]，因为它极大地改进了对管道文件的解析，否则它将使用自己的 YAML 解析器作为后备，并且并不差。这些解析器之间存在细微的差异，所以为什么不两者都具备呢？

用户测试

在 Ubuntu 16.04 LTS、Ubuntu 18.04 LTS、Ubuntu 20.04 LTS 和装有 PHP 和 Docker 的 Mac OS X Sierra 和 High Sierra 上成功使用。

已知错误

  • 在管道 exec 层中的命令 ":" 永远不会真正执行，而是模拟执行，具有退出状态 0 以及没有标准输出或错误输出。这是为了管道测试而设计的。

  • 括号扩展（用于大括号的 glob 模式）在某些情况下已知会失败。这 可能 影响匹配管道、收集资产路径，并 确实 影响构建 phar 文件。

    对于前两个，这 从未 被报告或经历，对于构建 phar 文件，解决方案是包含较大的模式部分。

  • 基于sf2yaml的解析器不支持在行尾使用反斜杠进行折叠，并且双引号字符串之间没有空格。

  • 基于libyaml的解析器不支持锚点名称中使用点 (.)。

  • 基于libyaml的解析器不支持将折叠的标量 (>) 作为块样式指示符。建议使用字面量样式 (|)。

  • 由于PHP运行时中对passthru的深度保护，以防止空字符注入，NUL字节 (\0) 在步骤脚本中不支持直接使用。

  • 当项目目录很大（例如，几GB）并且将其复制到管道容器中时，由于复制操作正在进行且耗时较长，可能会出现管道似乎挂起的情况。

    按ctrl + c可能停止管道，但不会停止复制操作。通过终止复制操作的进程（例如，将tar管道到docker cp）来停止操作。

安装

Phar（下载） | Composer | Phive | 源（包括Phar） | 完整项目（开发）

可以通过从Github下载phar存档、通过Composer/Packagist或使用Phive进行安装，并且应始终从源安装，这包括构建phar文件。

下载PHAR（PHP存档）文件

下载可在Github上找到。要获取最新发布的版本，请使用以下URL

https://github.com/ktomk/pipelines/releases/latest/download/pipelines.phar

将phar文件重命名为“pipelines”，设置可执行位，并将其移动到包含可执行文件的目录中。

从版本0.0.4起，Github上的下载可用。所有版本都在以下网站上列出

https://github.com/ktomk/pipelines/releases

使用Composer安装

建议全局安装（并且要确保全局composer vendor/bin在$PATH中）以便容易调用，并且本地项目中没有依赖关系

$ composer global require ktomk/pipelines

这将自动安装最新版本。通过调用pipelines并输出版本来验证安装

$ pipelines --version
pipelines version 0.0.19

要卸载，请删除包

$ composer global remove ktomk/pipelines

查看Composer from getcomposer.org [COMPOSER]，PHP的依赖管理器。Pipelines支持基于Composer的安装，可能包括上游补丁（支持composer 2，包括上游补丁）。

使用Phive安装

当有phive时，可能是最简单的安装方法

$ phive install pipelines

即使您的PHP版本没有Yaml扩展，这应该也能正常工作。如果您使用composer并且是PHP爱好者，请深入研究phive以适应您的系统和工作流程。

查看Phive from phar.io [PHARIO]，PHAR安装和验证环境（PHIVE）。Pipelines完全支持phar.io/phar基于的安装，包括对phive实用程序的支持，包括上游补丁。

从源安装

要从源安装，检出源代码库，并将可执行文件bin/pipelines符号链接到$PATH的一个部分，例如您的$HOME/bin目录或类似目录。通过调用pipelines并输出版本来验证安装

$ pipelines --version
pipelines version 0.0.19 # NOTE: the version is exemplary

要从源创建phar存档，请在项目根目录中调用构建脚本

$ composer build
building 0.0.19-1-gbba5a43 ...
pipelines version 0.0.19-1-gbba5a43
file.....: build/pipelines.phar
size.....: 240 191 bytes
SHA-1....: 9F118A276FC755C21EA548A77A9DBAF769B93524
SHA-256..: 0C38CBBB12E10E80F37ECA5C4C335BF87111AC8E8D0490D38683BB3DA7E82DEF
file.....: 1.1.0
api......: 1.1.1
extension: 2.0.2
php......: 7.2.16-[...]
uname....: [...]
count....: 62 file(s)
signature: SHA-1 E638E7B56FAAD7171AE9838DF6074714630BD486

phar存档随后就是（如构建输出所示）

build/pipelines.phar

通过调用它来检查版本

$ build/pipelines.phar --version
pipelines version 0.0.19-1-gbba5a43
# NOTE: the version is exemplary
PHP兼容性和未定义行为

Pipelines项目旨在支持php 5.3.3至php 8.1。

使用具有命名参数的任何PHP函数或方法都属于未定义行为。

可重现的Phar构建

管道项目自首次生成 Phar 文件以来就实践可重现构建。构建是自包含的，这意味着仓库包含构建所需的所有文件，只有很少的依赖项。

Phar 文件的可重现构建如果没有来自 composer 项目 phar-utils（Seldaek/Jordi Boggiano）的出色工作将是不完整的，该工具被管道项目在 Timestamps.php 中分叉，同时保留文件的原始许可证（MIT），在该许可证下提供上游的错误修复（参见 Phar-Utils #2 和 Phar-Utils #3）。

该文件用于将 Phar 文件内部的日期和时间设置为发布时的日期，否则这些日期将是在构建时的时间。这与 Composer 项目所做的相同（参见 Composer #3927）。

此外，在管道项目中，该文件还用于更改 Phar 文件中文件的访问权限。这是因为跨 PHP 版本的行为已发生变化，因此构建保持前后兼容。由于在项目历史的后期才注意到这一点，构建可能会根据使用的 PHP 版本显示不同的二进制文件（参见 PHP #77022 和 PHP #79082），以及时间戳文件的补丁状态。

安装完整项目进行开发

当使用 git 时，克隆仓库，然后调用 composer install。项目随后设置为开发模式。

或者，也可以通过 composer 直接完成相同的操作

$ composer create-project --prefer-source --keep-vcs ktomk/pipelines
...
$ cd pipelines

通过调用本地构建来验证安装

$ composer ci

如果一切顺利，应该退出状态为 0，如果存在问题，则非 0。Composer 会告诉哪个单独的脚本失败。

按照 从源安装 的说明使用开发版本的 pipelines。

待办事项

  • 支持私有 Docker 仓库
  • 如果启用了 docker 服务，则注入 docker 客户端
  • 仅运行管道的特定步骤（仅限）以在出现错误时将用户放回命令行，而无需重新运行所有内容
  • 在手动步骤处停止（使用 --no-manual 覆盖）
  • 支持 BITBUCKET_PR_DESTINATION_BRANCH 与 --trigger pr:<source>:<destination>
  • 管道服务
  • 使用 --user 作为当前用户运行（--deploy mount 应不再强制容器默认用户 [通常是 "root"] 用于项目文件操作），然而 Docker 工具仍然需要你（当前用户）具有 root 权限，因此技术上没有多少优势（参见 无根管道，以了解在此方面的更好操作）
  • 每个项目都有自己的缓存
  • 将本地 composer 缓存复制到容器中，以在 PHP 项目中获得更好的（离线）使用（参见 填充缓存）
  • 如果可用，则使用 /bin/bash 运行脚本（#17）（bash-runner 功能）
  • 在管道中支持 BITBUCKET_DOCKER_HOST_INTERNAL 环境变量 / host.docker.internal 主机名
  • 按项目基础计 BITBUCKET_BUILD_NUMBER（build-number 功能）
  • 可选不挂载docker.sock
  • 限制项目的路径在$HOME以下，排除点.目录的子目录。
  • 离线准备更方便（例如--docker-pull-images，--go-offline或类似选项）
  • 在运行管道之前检查Docker是否存在
  • 支持管道功能（管道特性）
    • 显示带有管道的脚本
    • 使用管道的模拟运行脚本以显示信息
    • 创建测试/演示管道
    • 带有管道的运行脚本
  • 关于与Bitbucket Pipelines的差异的说明
  • 关于支持的文件格式及其限制的说明
  • 管道文件属性支持
    • step.after-script（after-script特性）
    • step.trigger（--steps / --no-manual选项）
    • step.caches（要禁用，请使用--no-cache选项）
    • 定义
      • services（services特性）
      • caches（caches特性）
    • step.condition（#13）
    • clone（git-deployment特性）
    • max-time（本地运行通常不需要此功能）
    • size（本地运行可能被忽略，对Rootless Pipelines的支持有限）
  • 从工作目录获取VCS修订版本（git-deployment特性）
  • 使用不同的项目目录--project-dir <path>来指定部署到容器中的根路径，当前是工作目录（--working-dir <path>已经可以使用）
  • 在特定修订版上运行，引用它（--revision <ref>）；需要将干净的VCS签出复制到临时文件夹中，然后将该文件夹复制到容器中（git-deployment特性）
  • 覆盖默认镜像名称（--default-image <name>；本地运行通常不需要此功能）

参考