# 被 GitHub Action 坑了半天…

- Link: https://www.ixiqin.com/2021/01/12/by-making-the-action-pit-half-a-day/
- Published: 2021-01-12T23:03:32+08:00
- Author: 白宦成

我这几天在忙着搞 LCTT 的 Travis-CI 迁移到 Github Action 。整体的 CI 的流程都已经
迁移完成了，但是一个特定的检查脚本死活无法正常运行。

在这个过程中我尝试了多种办法，比如修改代码、调整里面的参数、打印其中的参数，似乎
都是工作运行正常的。

将项目代码 clone 到本地后，发现代码在本地运转也是正常的。

我一直不知道问题出在哪里，百思不得其解。直到我在跑了几百次 Action 构建后，我发现，
Github 默认的 checkout 插件是有问题的。

和标准的 git clone 不同， Github 默认的 Checkout 插件在实际 clone 项目是使用的不是`
git clone` 命令，而是采用先在本地 init 一个目录，并添加相应的 remote ，并 fetch 
代码下来。

![github action](http://static.zybuluo.com/xiqingongzi/7a9zhzyxnjvntd7ttkp9schk/
image.png)

GitHub Action 的 Clone

这样的好处是在处理的时候，只会 fetch 到特定的分支到本地，而不会将默认的其他分支一同
clone
到本地。但坏处就是你在执行的时候，只能针对特定的分支进行操作。

而检查脚本则是基于 git 本身的命令进行执行的，因此是需要比如 master 这样的分支的，
这就导致在使用了默认的 checkout 插件的时候，检查脚本无法使用。

![Travis-CI 的表现](https://postimg.aliavv.com/mbp2021/szjnw.png)

Travis CI 的 Clone

与之对比的，是 Travis CI 在执行 Clone 的时候，采用的是全量 Clone ，再单独 Fetch 
某个特定分支。从这个角度上来看，我可以理解 Github Action 为什么会 Clone 的更快一些。
不过，这种 Clone 的方式确实给一些 CI 在 Check 时留下隐患。

## 总结

如果你在 Github 中使用默认的 Checkout 插件获取项目以后，执行 Git 操作出现了问题，
很有可能是插件自己的问题，而不是你的问题。你可以选择自己构建 clone 命令，避免这个
问题。
