文章目录
通过Github Actions实现代码的持续集成(Continuous Integration/CI)(2)
基于git的workflow梳理

基于git的workflow可以总结为上图所示:
- 一个git仓库会有一个称之为main或master的主线,由仓库的拥有者(owner)以及维护者(maintainer)负责维护
- 仓库的主要日常开发人员(developer)check -b新建自己的开发分支(branch),在克隆(clone)到本地(local)后,进行代码的开发,开发的颗粒度称之为commit
- 在经过一些(当然也可以是一次)commit后,一般会将本地的代码变动push至远程(remote),push这一举动是CI的一个trigger event,它可以自动触发一个workflow。在workflow中可以自定义与该event相关联的操作。在例子仓库toy-tool中做了如下两件事情:
- 代码规范检查:用flake8来检查toy-tool库中提交的代码规范是否符合要求
- 单元测试:用Unittest对toy-tool库中功能进行单元测试
- 提交至远端(remote)的branch代码,通过以pr/mr颗粒度逐步的merge进main/master中
- 一般在多个(当然一个也可以)merge之后,会进行一次版本的发布(release) ,发布的前置操作是对代码仓库进行标签管理(tag)。release也是触发CI workflow的event。可以自己定义该workflow的内容,这里对toy-tool仓库的release workflow为:
- 代码规范检查
- 单元测试
- 对应pypi源分发包的生成以及上传
以toy-tool为例的CI实现
以toy-tool仓库为例。核心CI脚本如下:
push阶段对应的workflow:
name: GitHub Actions Demo
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
on: [push]
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install flake8
pip install pillow
pip install opencv-python
pip install opencv-python-headless
pip install numpy
- name: Check coding standard
run: flake8 .
- name: Unittest
run: python -m unittest discover tests
release阶段的核心脚本如下:
- name: Check coding standard
run: flake8 .
- name: Unittest
run: python -m unittest discover tests
- name: Update VERSION file
run: echo "${{ github.event.release.tag_name }}" > VERSION
- name: Build package
run: python -m build
- name: Publish package
uses: pypa/gh-action-pypi-publish@27b31702a0e7fc50959f5ad993c78deac1bdfc29
with:
user: ${{ secrets.PYPI_USER_TOKEN }}
password: ${{ secrets.PYPI_API_TOKEN }}
需要强调的有三点:
- 将release关联的tag名字,写入了一个称之为VERSION文件中。这一步与toy-tool仓库中setup.py中的对应代码相配合,完成源分发包版本号的动态更新。
def read_version():
import subprocess
result = subprocess.run(['ls', '-la'], capture_output=True, text=True)
print(result.stdout)
with open("VERSION", "r", encoding="utf-8") as fh:
version = fh.read()
return version
...
version=read_version(),
...
另外需要新建一个MANIFEST.in,显式的将VERSION文件包含在源分发包中。
2. 这里调用了github提供的一个用于python包发布的action,等价于通过pypi包来降低代码的复杂性和避免重复代码中对应的=具体指令。
- name: Build package
run: python -m build
- name: Publish package
uses: pypa/gh-action-pypi-publish@27b31702a0e7fc50959f5ad993c78deac1bdfc29
3.这里使用了github中的secrets特性来存放PYPI的pypi_user_token和pypi_api_token凭证。这里的secrets与github仓库相绑定,仅有仓库的owner和maintainer有权利查看。实现了pypi包上传时的无感化。
with:
user: ${{ secrets.PYPI_USER_TOKEN }}
password: ${{ secrets.PYPI_API_TOKEN }}
效果
基于上述workflow的配置,可以成功的通过github release界面点击、配置方式,完成了toytool pypi包的打包上传,而不需要记忆任何pypi包打包上传的机制和指令,将更多的精力投放在具体的特性开发上。
根据提示在对应的https://pypi.org/project/toytool/0.0.2/网页上见到最新发布的pypi包。
rethink
至此通过两篇文章介绍了github actions来实现持续集成的方法,短期内不会再撰写该系列的内容。
通过集成的持续化和自动化,可以得到如下好处:
- 将软件工程师从繁琐的重复操作中解放出来
- 避免软件工程师记忆一些没必要的指令和账户密码
- 主观上增强软件工程师版本发布的信心,客观上确实提高了软件工程师版本发布的质量
反过来思考,也应该将上述这三点作为出发点,反过来在尚没有github actions workflow的领域搭建类似该思想的机制。
相关文章和资源
该文章前置文章:通过Github Actions实现代码的自动化持续集成(Continuous Integration/CI)(1)
该文章包含流程图的drawio资源:https://download.youkuaiyun.com/download/u011345885/89856312?spm=1001.2014.3001.5501