通过Github Actions实现代码的持续集成（Continuous Integration/CI）(2)

学弟

已于 2024-10-07 19:55:39 修改

阅读量592

点赞数 17

分类专栏： # 快捷文章标签： github ci/cd event trigger

于 2024-10-07 19:18:26 首次发布

本文为博主原创文章，未经博主允许不得转载。

本文链接：https://blog.csdn.net/u011345885/article/details/142741045

版权

快捷专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章目录

通过Github Actions实现代码的持续集成（Continuous Integration/CI）(2)

通过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中做了如下两件事情：
1. 代码规范检查：用flake8来检查toy-tool库中提交的代码规范是否符合要求
2. 单元测试：用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包。