通过Github Actions实现代码的持续集成(Continuous Integration)(1)
问题的提出
无论是"通过pypi包来降低代码的复杂性和避免重复代码"文章中提到的toy-tool代码还是实际工作中的业务代码,通过代码管理工具对其进行管理是重要的。常见的代码管理工具有github、gitlab(以及svn)。通常来讲,gitlab用来管理公司的私有代码仓库,github则常用于开源代码的管理。
本文介绍的CI(Continuous Integration)是gitlab以及github所提供的功能的子集,很重要但常易被忽略。一方面原因是因为CI是一个底层机制,该机制一般由仓库的owner建立,所以仓库的developer很难涉及到这部分;另外一方面CI机制一旦建立之后,后来者只需负责代码的开发和提交,无感带来忽略。
但作为一个成熟的软件工程师,对CI还是要有一定的了解。计划是采用2篇文章,利用github中的actions对CI进行学习。本文是第一篇:主要强调CI的意义并记录github actions的初体验。
Github Actions 初体验
actions的实践需要一个着力点,这里将"通过pypi包来降低代码的复杂性和避免重复代码"中的代码存放至github平台处,作为后续实践的对象。https://github.com/johnson-magic/toy-tool。
如何做
建立自己CI机制的具体步骤可以总结为
mkdir -p .github/workflows
cd .github/workflows
touch github-actions.yaml
其中github-actions.yaml的内容为:
name: GitHub Actions
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
on: [push]
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
- name: Check out repository code
uses: actions/checkout@v4
- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
- run: echo "🖥️ The workflow is now ready to test your code on the runner."
- name: List files in the repository
run: |
ls ${{ github.workspace }}
- run: echo "🍏 This job's status is ${{ job.status }}."
效果如何
如上图所示,当commit 9f85a5e被push,自动触发了github action一次ci行为。因为该ci仅仅是一个echo操作,共耗时12s即结束了(当然,事实上CI会比此更加复杂,但这些内容不是本篇文章的核心,在第二篇文章中再对其做展开)。
rethink
CI之所以重要,是因为它是软件工程领域一个公认的思想”每日构建和冒烟测试“的具体实现。可以在CI中规范不同开发者的代码撰写习惯、及时发现代码变动可能引入的错误、粘合各种构建、集成的繁琐重复工作并自动完成以及增强开发者对代码仓库质量的信心。在第二篇的CI相关文章中会看到
- flake8对代码规范的统一
- 单元测试
- 编译、连接
- 发布
成熟的CI会包含(不局限于)上述流程的自动化。而这些操作都是被push或者打tag等git操作自动触发。自动触发,这是一种优雅的计算机思维的体现。
参考资料
https://docs.github.com/en/actions/writingworkflows/quickstart