今天做一个项目，提交到Github后，自己居然收到了一封邮件，长这个样子。
看到这封邮件，意思是Github帮我跑了个脚本，没通过，通过邮件给我发了个通知。
这东西我还算熟悉，之前实习的时候，就有流水线这个东西，我在自己的分支提交代码后，再提一个MR，就会自动跑这个流水线，流水线包含一些脚本。
如果流水线过了，同事会Code Review，可以就合并到主分支，如果流水线没过我就还得看是不是自己写的哪里有问题。
之前一直以为这一套是公司的基础设施，原来Github上就可以搞。
在本地的文件夹里找了找，发现Github跑的脚本在.github/workflows中，不是一个shell脚本，而是一个yml文件。
这个yml文件里的东西应该是Github规定的一些语法，不过这个不重要。第一次发现Github还能干这个，出于好奇就上网搜了搜，原来这套东西是有学名的。
持续集成：指频繁的合并代码到主干，合并时必须通过测试，有利于快速发现错误，且可以避免合并代码时和主干diff过多，加重Code Review的复杂性。
和持续集成相关的还有两个概念。
持续交付：指频繁的将代码交给QA评审，评审通过后就可以发布到生产环境。
持续部署：指发布到生产环境应该是自动完成的。
之前实习的时候其实团队里没有QA，所以交付这一步也合并到了流水线完成，就是跑一些单元测试和集成测试。
这个PUSH或MR后跑测试的行为也有个名字，叫HOOK，在.git中也可以配置相应的HOOK，之前就试过做一个cpplint的HOOK，在PUSH的时候检查代码规范。
Github的这一套称为Action，持续集成、持续交付、持续部署都可以用这个Action来做，也就是把相应的行为写到流水线中。
