| 编辑推荐: |
本文将用三种方法来创建
CI/CD 流水线。Monad 不能对流水线进行静态分析，Arrow 语法很难用，我称之为
Dart（不知道它是否已经有名字了）的一种轻量级的 Arrow 方法可以像 Arrow
一样进行静态分析，但语法比 Monad 更简单。
本文来自于infoq，由火龙果软件Anna编辑推荐。 |
|
我需要构建一个用于创建 CI/CD 流水线的系统。它起初是为了构建一个
CI 系统，测试 Github 上的 OCaml 项目（针对多个版本的 OCaml 编译器和多个操作系统，测试每个提交）。下面是一个简单的流水线，获取某个
Git 分支最新的提交，构建，并执行测试用例。
【译者注】CI/CD：持续集成（Continuous Integration）和持续部署（Continuous
Deployment）简称，指在开发过程中自动执行一系列脚本来减低开发引入 bug 的概率，在新代码从开发到部署的过程中，尽量减少人工的介入。
这里的配色标识是：绿色的方框是已经完成，橙色的是正在进行，灰色的意味着这一步还不能开始。
这里有一个稍微复杂点的例子，它还下载了一个 Docker 基础镜像，使用两个不同版本的 OCaml
编译器并行构建提交，然后测试得到的镜像。红框表示此步骤失败：
一个更复杂的例子是测试项目本身，然后搜索依赖它的其他项目，并根据新版本测试这些项目：
在这里，圆圈意味着在检查反向依赖项之前，我们应该等待测试通过。
我们可以用 YAML 或类似的方法来描述这些管道，但这将是非常有限的。相反，我决定使用一种特定于领域的嵌入式语言，这样我们就可以免费使用宿主语言的特性（例如字符串操作、变量、函数、导入、类型检查等）。
最明显的方法是使每个框成为正则函数。然后上面的第一个例子可以是（这里，使用
OCaml 语法）：
let example1
commit =
let src = fetch commit in
let image = build src in
test image |
第二个可能是：
let example2
commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2"
in
let build ocaml_version =
let dockerfile = make_dockerfile ~base ~ocaml_version
in
let image = build ~dockerfile src ~label:ocaml_version
in
test image
in
build "4.07";
build "4.08" |
第三个可能是这样的：
let example3
commit =
let src = fetch commit in
let image = build src in
test image;
let revdeps = get_revdeps src in
List.iter example1 revdeps |
不过，我们想在语言中添加一些附加功能：
管道步骤应尽可能并行运行。上面的 example2 函数将一次完成一个构建。
管道步骤应在其输入更改时重新计算。e、 当我们作出新的承诺时，我们需要重建。
用户应该能够查看每个步骤的进度。
用户应该能够为任何步骤触发重建。
我们应该能够从代码中自动生成图表，这样我们就可以在运行管道之前看到它将做什么。
一步的失败不应该使整个管道停止。
对于这篇博客文章来说，确切的附加功能并不重要，因此为了简单起见，我将重点放在同时运行步骤上。
Monad 方法
【译者注】Monad：函子，单子，来自 Haskell 编程语言，是函数式编程中，一种定义将函数（函子）组合起来的结构方式，它除了返回值以外，还需要一个上下文。常见的
Monad 有计算任务，分支任务，或者 I/O 操作。
如果没有额外的功能，我们有如下功能：
val fetch : commit
-> source
val build : source -> image |
您可以将其理解为“build 是一个获取源值并返回（Docker）镜像的函数”。
这些函数很容易组合在一起，形成一个更大的函数来获取提交并构建它：
let fab c =
let src = fetch c in
build src |
我们还可以将其缩短为 build（fetch c）或 fetch c |>build。OCaml
中的|>（pipe）运算符只调用其右侧的函数，而参数在其左侧。
为了将这些函数扩展为并发的，我们可以让它们返回承诺，例如，
val fetch : commit
-> source promise
val build : source -> image promise |
但是现在我们无法使用 let（或|>）轻松组合它们，因为 fetch 的输出类型与 build
的输入不匹配。
但是，我们可以定义一个类似的操作，let（或>>=）来处理承诺。它立即返回对最终结果的承诺，并在第一个承诺实现后调用
let* 的主体。那么我们有：
let fab c =
let* src = fetch c in
build src |
换句话说，通过在周围撒上几个星号字符，我们可以将简单的旧管道变成一个新的并发管道！使用 let*
编写 promise returning 函数的时间规则与使用 let 编写常规函数的时间规则完全相同，因此使用
promise 编写程序与编写常规程序一样简单。
仅仅使用 let *不会在我们的管道中添加任何并发（它只允许它与其他代码并发执行）。但是我们可以为此定义额外的函数，比如
all 一次计算一个列表中的每个承诺，或者使用 and 运算符指示两个事物应该并行运行：
除了处理承诺外，我们还可以为可能返回错误的函数（只有在第一个值成功时才调用 let 的主体）或为实时更新（每次输入更改时都调用主体）或为所有这些东西一起定义
let*。这是单子的基本概念。
这其实很管用。在 2016 年，我用这种方法做了 DataKitCI，它最初用于 Docker-for-Mac
上的 CI 系统。之后，Madhavapeddy 用它创建了 opam-repo-ci，这是 opam-repository
上的 CI 系统，OCaml 上主要的软件仓库。这将检查每个新的 PR 以查看它添加或修改了哪些包，针对多个
OCaml 编译器版本和 Linux 发行版（Debian、Ubuntu、Alpine、CentOS、Fedora
和 OpenSUSE）测试每个包，然后根据更改的包查找所有包的所有版本，并测试这些版本。
使用 monad 的主要问题是我们不能对管道进行静态分析。考虑上面的 example2 函数。在查询
GitHub 以获得测试提交之前，我们无法运行该函数，因此不知道它将做什么。一旦我们有了 commit，我们就可以调用
example2commit，但是在 fetch 和 docker_pull 操作完成之前，我们无法计算
let* 的主体来找出管道接下来将做什么。
换言之，我们只能绘制图表，显示已经执行或正在执行的管道位，并且必须使用和 * 手动指示并发的机会。
Arrow 方法
Arrow 使管道的静态分析成为可能。而不是我们的一元函数：
val fetch : commit
-> source promise
val build : source -> image promise |
我们可以定义箭头类型：
type ('a, 'b)
arrow
val fetch : (commit, source) arrow
val build : (source, image) arrow |
a（'a，'b）arrow 是一个接受 a 类型输入并生成 b 类型结果的管道。如果我们定义类型（'a，'b）arrow='a->'b
promise，则这与一元版本相同。但是，我们可以将箭头类型抽象化，并对其进行扩展，以存储我们需要的任何静态信息。例如，我们可以标记箭头：
type ('a, 'b)
arrow = {
f : 'a -> 'b promise;
label : string;
} |
这里，箭头是一个记录。f 是旧的一元函数，label 是“静态分析”。
用户看不到 arrow 类型的内部，必须使用 arrow 实现提供的函数来构建管道。有三个基本功能可用：
val arr : ('a
-> 'b) -> ('a, 'b) arrow
val ( >>> ) : ('a, 'b) arrow -> ('b,
'c) arrow -> ('a, 'c) arrow
val first : ('a, 'b) arrow -> (('a * 'c), ('b
* 'c)) arrow |
arr 接受纯函数并给出等价的箭头。对于我们的承诺示例，这意味着箭头返回已经实现的承诺。>>>把两个箭头连在一起。首先从“a”到“b”取一个箭头，改为成对使用。该对的第一个元素将由给定的箭头处理，第二个组件将原封不动地返回。
我们可以让这些操作自动创建带有适当 f 和 label 字段的新箭头。例如，在 a>>>b
中，结果 label 字段可以是字符串{a.label}>>{b.label}。这意味着我们可以显示管道，而不必先运行它，如果需要的话，我们可以很容易地用更结构化的内容替换
label。
我们的第一个例子是：
let example1
commit =
let src = fetch commit in
let image = build src in
test image |
to
let example1
=
fetch >>> build >>> test |
虽然我们不得不放弃变量名，但这似乎很令人愉快。但事情开始变得复杂，有了更大的例子。例如
2，我们需要定义几个标准组合：
(** Process the
second component of a tuple, leaving the first
unchanged. *)
let second f =
let swap (x, y) = (y, x) in
arr swap >>> first f >>> arr
swap
(** [f *** g] processes the first component of
a pair with [f] and the second
with [g]. *)
let ( *** ) f g =
first f >>> second g
(** [f &&& g] processes a single value
with [f] and [g] in parallel and
returns a pair with the results. *)
let ( &&& ) f g =
arr (fun x -> (x, x)) >>> (f *** g) |
Then, example2 changes from:
let example2
commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2"
in
let build ocaml_version =
let dockerfile = make_dockerfile ~base ~ocaml_version
in
let image = build ~dockerfile src ~label:ocaml_version
in
test image
in
build "4.07";
build "4.08" |
to:
let example2
=
let build ocaml_version =
first (arr (fun base -> make_dockerfile ~base
~ocaml_version))
>>> build_with_dockerfile
~label:ocaml_version
>>> test
in
arr (fun c -> ((), c))
>>> (docker_pull
"ocaml/opam2" *** fetch)
>>>
(build "4.07" &&& build
"4.08")
>>> arr (fun ((), ()) -> ()) |
我们已经丢失了大多数变量名，而不得不使用元组，记住我们的值在哪里。这里有两个值并不是很糟糕，但是随着更多的值被添加并且我们开始嵌套元组，它变得非常困难。我们还失去了在
build~dockerfile src 中使用可选标记参数的能力，而是需要使用一个新操作，该操作接受
dockerfile 和源的元组。
假设现在运行测试需要从源代码获取测试用例。在原始代码中，我们只需使用：src 将测试图像更改为测试图像。在
arrow 版本中，我们需要在生成步骤之前复制源代码，使用带 dockerfile 的 first
build_ 运行生成，并确保参数是新测试使用的正确方法。
Dart 方法
我开始怀疑是否有一种更简单的方法来实现与箭头相同的静态分析，但是没有无点语法，而且似乎有。考虑示例
1 的一元版本。我们有：
val build : source
-> image promise
val test : image -> results promise
let example1 commit =
let* src = fetch commit in
let* image = build src in
test image |
如果你不知道蒙娜兹的事，你还有别的办法。您可以定义 build 和
test，将 promises 作为输入，而不是使用 let* 等待获取完成，然后使用源调用 build：
val build : source
promise -> image promise
val test : image promise -> results promise |
毕竟，fetching 给了你一个源代码承诺，你想要一个图像承诺，所以这看起来很自然。我们甚至可以以承诺为例。然后看起来是这样的：
let example1
commit =
let src = fetch commit in
let image = build src in
test image |
很好，因为它和我们刚开始的简单版本是一样的。问题是效率低下：
我们用承诺的方式调用 example1（我们还不知道它是什么）。
我们不必等待找出要测试的提交，而是调用 fetch，获取某个源的承诺。
不需要等待获取源代码，我们就调用 build，获取图像的承诺。
不用等待构建，我们调用 test，得到结果的承诺。
我们立即返回测试结果的最终承诺，但我们还没有做任何真正的工作。相反，我们建立了一长串的承诺，浪费了记忆。
但是，在这种情况下，我们希望执行静态分析。i、 我们想在内存中建立一些表示流水线的数据结构……这正是我们对
monad 的“低效”使用所产生的结果！
为了使其有用，我们需要基本操作（比如 fetch）来为静态分析提供一些信息（比如标签）。OCaml
的 let 语法没有为标签提供明显的位置，但是我能够定义一个运算符（let**），该运算符返回一个接受
label 参数的函数。它可用于生成如下基本操作：
let fetch commit
=
"fetch" |>
let** commit = commit in
(* (standard monadic implementation of fetch goes
here) *) |
因此，fetch 接受一个提交的承诺，对它执行一个单字节绑定以等待实际的提交，然后像以前一样继续，但它将绑定标记为一个
fetch 操作。如果 fetch 包含多个参数，则可以使用 and* 并行等待所有参数。
理论上，let**In fetch 的主体可以包含进一步的绑定。如果那样的话，我们在一开始就无法分析整个管道。但是，只要原语在开始时等待所有输入，并且不在内部进行任何绑定，我们就可以静态地发现整个管道。
我们可以选择是否将这些绑定操作公开给应用程序代码。如果 let*（或 let**）被公开，那么应用程序就可以使用
monad 的所有表达能力，但是在某些承诺解决之前，我们将无法显示整个管道。如果我们隐藏它们，那么应用程序只能生成静态管道。
到目前为止，我的方法是使用 let* 作为逃生舱口，这样就可以建造任何所需的管道，但我后来用更专业的操作来代替它的任何用途。例如，我添加了：
| val list_map
: ('a t -> 'b t) -> 'a list t -> 'b list
t |
这将处理运行时才知道的列表中的每个项。然而，我们仍然可以静态地知道我们将应用于每个项的管道，即使我们不知道项本身是什么。list_map
本来可以使用 let* 实现，但这样我们就无法静态地看到管道。
下面是另外两个使用 dart 方法的示例：
let example2
commit =
let src = fetch commit in
let base = docker_pull "ocaml/opam2"
in
let build ocaml_version =
let dockerfile =
let+ base = base in
make_dockerfile ~base ~ocaml_version in
let image = build ~dockerfile src ~label:ocaml_version
in
test image
in
all [
build "4.07";
build "4.08"
] |
与原来相比，我们有一个 all 来合并结果，并且在计算 dockerfile
时有一个额外的 let+base=base。let+ 只是 map 的另一种语法，在这里使用，因为我选择不更改
make_dockerfile 的签名。或者，我们可以让你的 dockerfile 接受一个基本图像的承诺，并在里面做地图。因为
map 需要一个纯实体（make_dockerfile 只生成一个字符串；没有承诺或错误），所以它不需要在图表上有自己的框，并且我们不会因为允许使用它而丢失任何东西。
let example3
commit =
let src = fetch commit in
let image = build src in
let ok = test image in
let revdeps = get_revdeps src in
gate revdeps ~on:ok |>
list_iter ~pp:Fmt.string example1 |
这显示了另一个自定义操作：gate revdeps~on:ok 是一个承诺，只有在 revdeps
和 ok 都解决后才能解决。这将阻止它在库自己的测试通过之前测试库的 revdeps，即使如果我们希望它可以并行地这样做。而对于
monad，我们必须在需要的地方显式地启用并发（使用和 *），而对于 dart，我们必须在不需要的地方显式地禁用并发（使用
gate）。
我还添加了一个 list-iter 便利函数，并为它提供了一个漂亮的 printer 参数，这样一旦知道列表输入，我们就可以在图表中标记案例。
最后，虽然我说过不能在原语中使用 let*，但仍然可以使用其他一些 monad（它不会生成图）。实际上，在实际系统中，我对原语使用了一个单独的
let>操作符。这就要求主体使用底层 promise 库提供的非图生成承诺，因此不能在原语的主体中使用
let*（或 let>）。
和 Arrow 进行比较
给定一个“dart”，您可以通过定义例如。
| type ('a, 'b)
arrow = 'a promise -> 'b promise |
那么 arr 就是 map，f>>>g 就是有趣的 x->g（fx）。第一个也可以很容易地定义，假设你有某种函数来并行地做两件事（比如上面的和我们的）。
因此，dart API（即使有 let*hidden）仍然足以表示任何可以使用箭头 API 表示的管道。
Haskell 箭头教程 使用一个箭头是有状态函数的示例。例如，有一个 total 箭头，它返回它的输入和以前调用它的每个输入的总和。e、
g. 用输入 1 2 3 调用三次，产生输出 1 3 6。对输入序列运行管道将返回输出序列。
本教程使用 total 定义 mean1 函数，如下所示：
| mean1 = (total
&&& (arr (const 1) >>> total))
>>> arr (uncurry (/)) |
因此，此管道复制每个输入编号，将第二个编号替换为 1，将两个流相加，然后用其比率替换每对。每次将另一个数字放入管道时，都会得到迄今为止输入的所有值的平均值。
使用 dart 样式的等效代码是（OCaml 使用 /。对于浮点除法）：
let mean values
=
let t = total values in
let n = total (const 1.0) in
map (uncurry (/.)) (pair t n) |
这对我来说更容易理解。通过定义标准运算符 let+（对于 map）和
+（对于 pair），我们可以稍微简化代码：
let (let+) x
f = map f x
let (and+) = pair
let mean values =
let+ t = total values
and+ n = total (const 1.0) in
t /. n |
无论如何，这不是一个很好的箭头示例，因为我们不使用一个状态函数的输出作为另一个状态函数的输入，所以这实际上只是一个简单的
applicative.
不过，我们可以很容易地用另一个有状态函数扩展示例管道，也许可以添加一些平滑处理。这看起来像箭头符号中的
mean1>>>平滑，省道符号中的值|>平均值|>平滑（或平滑（平均值））。
注意：Haskell 还有一个 Arrows 语法扩展，它允许 Haskell
代码编写为：
mean2 = proc
value -> do
t <- total -< value
n <- total -< 1
returnA -< t / n |
这更像是飞镖符号。
更多示例
我在 ocurrent/ocurrent 上建立了一个使用这些思想的稍微扩展版本的库。子目录 lib_term
是与这篇博客文章相关的部分，在 TERM 中描述了各种组合词。
其他目录处理更具体的细节，例如与 Lwt promise 库的集成，提供管理 web UI 或 Cap’n
Proto RPC 接口，以及带有用于使用 Git、GitHub、Docker 和 Slack 的原语的插件。
OCaml Docker 基础镜像构建
ocurrent/docker-base-images 包含一个管道，用于为各种
Linux 发行版、CPU 架构、OCaml 编译器版本和配置选项构建 OCaml 的 Docker
基本映像。例如，要在 Debian 10 上测试 OCAML4.09，可以执行以下操作：
$ docker run
--rm -it ocurrent/opam:debian-10-ocaml-4.09
:~$ ocamlopt --version
4.09.0
:~$ opam depext -i utop
[...]
:~$ utop
----+--------+------------------
| Welcome to utop version 2.4.2 (using OCaml version
4.09.0)! |
+---------------------------+
Type #utop_help for help about using utop.
-( 11:50:06 )-< command 0 > -------------{
counter: 0 }-
utop #
|
以下是管道的外观（单击可查看完整尺寸）
它每周提取 opam 存储库的最新 Git 提交，然后为每个发行版构建包含该内容的基本映像和 opam
包管理器，然后为每个受支持的编译器变体构建一个映像。许多图片是建立在多个架构（amd64、arm32、arm64
和 ppc64）上的，并被推到 Docker Hub 的一个暂存区。然后，管道将所有散列组合起来，将一个多架构清单推送到
Docker Hub。还有一些别名（例如，debian 表示 debian-10-ocaml-4.09）。最后，如果有任何问题，则管道会将错误发送到松弛通道。
您可能想知道，我们是否真的需要一个管道来实现这一点，而不是从 cron 作业运行一个简单的脚本。但是拥有一个管道可以让我们在运行它之前看到管道将要做什么，观察管道的进度，单独重新启动失败的作业，等等，几乎与我们编写的代码相同。
如果你想看完成的流水线，可以阅读 pipeline.ml。
OCaml CI
ocurrent/ocaml-ci 是一个用于测试 OCaml 项目的（实验性的）GitHub 应用程序。管道获取应用程序的安装列表，获取每个安装的已配置存储库，获取每个存储库的分支和
PRs，然后针对多个 Linux 发行版和 OCaml 编译器版本测试每个存储库的头部。如果项目使用
ocamlformat，它还会检查提交的格式是否与 ocamlformat 的格式完全相同。
结果作为提交状态被推回到 GitHub，并记录在 web 和 tty ui 的本地索引中。这里有很多红色，主要是因为如果一个项目不支持特定版本的
OCaml，那么构建会被标记为失败，并在管道中显示为红色，尽管在生成 GitHub 状态报告时会过滤掉这些失败。我们可能需要一个新的颜色跳过阶段。
结论
编写 CI/CD 管道很方便，就好像它们是一次连续运行这些步骤并始终成功的单点脚本一样，然后只要稍作更改，管道就会在输入更改时运行这些步骤，同时提供日志记录、错误报告、取消和重建支持。
使用 monad 可以很容易地将任何程序转换为具有这些特性的程序，但是，与常规程序一样，在运行某些数据之前，我们不知道该程序将如何处理这些数据。特别是，我们只能自动生成显示已经开始的步骤的图表。
传统的静态分析方法是使用箭头。这比单元格稍微有限，因为流水线的结构不能根据输入数据而改变，尽管我们可以增加有限的灵活性，例如可选的步骤或两个分支之间的选择。但是，使用箭头符号编写管道是很困难的，因为我们必须使用无点样式（没有变量）编程。
通过以一种不寻常的方式使用 monad（这里称为“dart”），我们可以获得静态分析的相同好处。我们的函数不是接受纯值并返回包装值的函数，而是接受并返回包装值。这导致语法看起来与普通编程相同，但允许静态分析（代价是无法直接操作包装的值）。
如果我们隐藏（或不使用）monad 的 let*（bind）函数，那么我们创建的管道总是可以静态地确定的。如果我们使用绑定，那么管道中会有随着管道运行而扩展到更多管道阶段的孔。
基本步骤可以通过使用单个“标签绑定”创建，其中标签为原子组件提供静态分析。
我以前从未见过使用过这种模式（或者在 arrow 文档中提到过），它似乎提供了与 arrow 完全相同的好处，而且难度要小得多。如果这个名字是真的，告诉我！
这项工作由 OCaml 实验室资助。 |
