基于 abapGit 和 abaplint 的 ABAP 持续集成的一个例子
这是 Jerry 2021 年的第 61 篇文章，也是汪子熙公众号总共第 338 篇原创文章。
短歌行
曹操
对酒当歌，人生几何！
譬如朝露，去日苦多。
慨当以慷，忧思难忘。
何以解忧？唯有杜康。
青青子衿，悠悠我心。
但为君故，沉吟至今。
呦呦鹿鸣，食野之苹。
我有嘉宾，鼓瑟吹笙。
明明如月，何时可掇？
忧从中来，不可断绝。
越陌度阡，枉用相存。
契阔谈讌，心念旧恩。
月明星稀，乌鹊南飞。
绕树三匝，何枝可依？
山不厌高，海不厌深。
周公吐哺，天下归心。
Jerry 之前写过一篇文章，使用 abapGit 在 ABAP On-Premises 系统和 SAP 云平台 ABAP 环境之间进行代码传输，介绍了 abapGit 这个开源工具的基本用法。
本文 Jerry 介绍基于 abapGit 和另一个开源工具，abaplint，实现 ABAP 持续集成的一个具体场景：当有新的代码提交到 ABAP 代码仓库时，自动触发 ABAP 代码检测。
当然，持续集成指的是，只要有新的代码提交，就自动运行构建和测试，反馈运行结果。仅当能确保新提交的代码符合预期，再将新代码集成到主干。因此本文介绍的例子，只是 ABAP 持续集成中的一个小步骤而已。
我们首先来简单了解一下 abaplint.使用 SAP UI5 开发的朋友们，想必都接触过 ESLint，一款 JavaScript 代码检测工具。
Jerry 每天用 Angular 开发 SAP Commerce Cloud UI，也借助了 Visual Studio Code 名为 TSLint 的扩展，来对 TypeScript 代码进行检测。
同样，abaplint 也是一款对 ABAP 代码根据指定的规则进行检测的开源工具，基于 TypeScript 编写。
下面是它的一个 demo 网站：
https://playground.abaplint.org/
其中 abaplint.json 是配置文件，定义了检测规则。违反规则的代码，会通过红色波浪线高亮出来：
我按照 abaplint 检测出来的提示对代码进行了调整，之后警告信息都消失了。
注意，abaplint 对代码的检测和 ABAP 服务器上的代码语法检查(Syntax Check)完全是两回事。后者由位于 ABAP 内核的 Compiler 完成，而前者只是 TypeScript 实现的基于源代码文本级别的检测，abaplint 本身并不能从语法层面识别 ABAP 语言，只是机械地基于文本静态分析，完成 abaplint.json 里定义的检测任务而已。
下面介绍如何配置 abapGit 和 abaplint 实现最简单的 ABAP 持续集成。这个例子不需要任何开发，仅仅包含一些配置工作，不超过半小时即可完成。
(1) 创建一个 Github 仓库存放 ABAP 代码。我选择把所有的 ABAP 代码放置在 src 文件夹内。
注意：abaplint 只能扫描特殊格式的 ABAP 代码文件，即经过 abapGit 提交的 ABAP 代码。
新建一个 .github 文件夹，里面放一个子文件夹 workflows, 包含一个 abaplint.yml 文件。
这个 abaplint.yml 文件，负责指定当该代码仓库有新的代码提交时，通过 Github Workflow 执行的操作内容。其中第2行开始的 on 指令，告诉 Github，当 main 分支有 push 或者 pull request 到来时，执行名为 abaplint 的 job. 而后者的工作内容，其具体步骤从第14行的 steps 指令开始定义。
第15行的 uses 指令，意思是重用 Github 自带的名为 setup-node action，完成 Node.js 运行环境的准备。
setup-node 这个 action 实现于如下的 Github 仓库：
https://github.com/actions/setup-node
而 run 命令里维护的如下命令行，意思是 Node.js 运行环境准备好之后，安装 abaplint 命令行工具并执行。
npm -g install @abaplint/cli
abaplint
(2) 根目录下新建 abaplint.json,定义 ABAP 代码检测规则。为了演示起见，我只启用了如下图所示的几条简单规则。关于 abaplint.json 支持的所有检测规则，请查阅这个链接：
https://github.com/abapGit/abapGit/blob/main/abaplint.json
完成 abaplint.yml 和 abaplint.json 两个文件的创建之后，提交任意代码到 main 分支，即可在代码仓库的 Actions 标签页里，看到针对这些代码提交，自动执行的 abaplint 检测记录：
单击一条进去，能查看到引起当前工作流执行失败的原因——代码违反了我自定义的 abaplint 检测规则：定义的关键字需要小写，使用了被标注为 obsolete 的关键字 ADD 等等。
目前开源社区里用于持续集成的构建和测试的自动化工具层出不穷，Jerry 工作的 SAP Commerce Cloud Spartacus UI 开发团队使用的是 Travis.
Travis 支持绑定 Github 的代码仓库，只要有新的代码提交，就会自动抓取。然后提供一个运行环境，执行测试，完成构建。
为了让我的 ABAP 代码仓库提交的代码能够被 Travis 抓取，我在项目根目录下创建了 .travis.yml 文件，内容如下图所示，其 script 区域的命令行和前文介绍的 abaplint.yml 内包含的内容完全一致，这里不再赘述。
完成 .travis.yml 文件的编辑之后，重新提交，登录 Travis 控制台，发现这次提交触发了一次新的 Travis 构建：
https://app.travis-ci.com/github/wangzixi-diablo/abap-ci-test
构建失败，原因还是因为违反了 abaplint.json 定义的那几条规则：
老老实实按照 abaplint 输出的结果把 ABAP 代码里所有违反规则之处修复，重新提交，这次 Github 工作流和 Travis 里的构建日志终于都显示绿灯了。
本文演示用的 ABAP 代码仓库地址如下：
https://github.com/wangzixi-diablo/abap-ci-test
总结
本文通过一个具体的例子，介绍了如何利用 abapGit 和 abaplint，以及 Travis，实现 ABAP 持续集成场景里基于新的代码提交，自动进行代码检测的步骤。
在实际的 SAP 产品开发项目中，持续集成的场景复杂度远远大于本例，因此通常都由专人甚至专门的团队来完成。
感谢阅读。
Jerry 的 ABAP 专题