04-15 周一 GitHub仓库CI服务器actions-runner和workflow yaml配置文档解析

04-15 周一 GitHub仓库CI服务器配置过程文档

时间	版本	修改人	描述
2024年4月15日10:35:52	V0.1	宋全恒	新建文档
2024年4月17日10:33:20	v1.0	宋全恒	完成github actions CI的配置和工作流配置文件解读文档的撰写

简介

一些基础概念

前提知识

仓库介绍

地址	镜像	介绍
https://github.com/CodexDive/LLMChat	harbor.alkaidos.cn/wxzhang/ragllm:latest	大模型应用

CI服务器介绍

(base) yangfei@ubuntu:~/actions-ci$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

建议定要使用和宿主机相同的自定义镜像来运行CI作业，不然可能会出现诸如GLIBC问题，即如果宿主机为Ubuntu 20.04，那么自定义镜像最好也是Ubuntu，并且版本是20.04这样稀奇古怪的问题遇到的会少许多。

配置过程

在仓库上查看配置指令

我们以LLMChat上查看为例，登录 LLMChat，查看

可以先去网址下载好actions-runner的客户端，也可以在安装的时候下载。在此演示基于网站上的程序下载安装器

具体的代码如下：

Download

# Create a folder
$ mkdir actions-runner && cd actions-runner# Download the latest runner package
$ curl -o actions-runner-linux-x64-2.315.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.315.0/actions-runner-linux-x64-2.315.0.tar.gz# Optional: Validate the hash
$ echo "6362646b67613c6981db76f4d25e68e463a9af2cc8d16e31bfeabe39153606a0  actions-runner-linux-x64-2.315.0.tar.gz" | shasum -a 256 -c# Extract the installer
$ tar xzf ./actions-runner-linux-x64-2.315.0.tar.gz

Configure

# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/CodexDive/LLMs_Inference --token BCTEUWK4VPIV2M4PKIRQX2TGDXVXC# Last step, run it!
$ ./run.sh

注意，配置的github账户，必须拥有这个仓库，才能配置和查看runner（对于个人账户而言）

注意，运行器的仓库位于GitHub actions-runner.当前最新版本为2.315.0，运行器的版本默认会自动升级，因此这个下载部分的链接可能会发生变化。

注意，关于配置时，配置的过程，如指定token和标签可以参考标签运行器

注意，如果想要同一个运行器运行多个仓库的作业，需要使用组织级的账户，对于个人账户，一个部署了运行器的服务器只能添加到一个仓库

配置CI服务器为运行器客户端

使用XShell等工具链接CI服务器，如42.将压缩包拷贝到某个目录，如/home/yangfei/actions-ci，以yangfei账户为CI服务启动的账户：

我们首先使用./configure 命令为启动器配置组、名称和标签

./config.sh --url https://github.com/CodexDive/LLMs_Inference --token BCTEUWK4VPIV2M4PKIRQX2TGDXVXC

上述命令会交互式的提醒用户输入运行器组名（个人仓库，无组），运行器名称zjlab-runner，标签为A100,40G,8C

分别表位GPU为A100, 内存容量为40G，8卡。工作目录为_work

一般配置完成之后，客户端会与GitHub进行通信，因此我们就可以在当前目录下执行

./run.sh

然后去网页上验证是否成功。一般没有问题，暂且不表，我们继续将该客户端安装成服务，这样重启之后，运行器服务会自动运行。

待执行的命令外:

sudo ./svc.sh install yangfei

服务的状态查看，停止和卸载可以参见下图

关于actions-runner的服务配置，也可以参见将自托管的运行应用策划给你续配置为服务

网页验证配置是否成功

在仓库上添加workflow配置文件

在我们配置好了运行器之后，可以在网页上查看运行的状态是否处于正常状态。

配置工作流

Github Actions 是GitHub的持续集成服务。持续集成由很多操作组成，比如登录远程服务器，发布内容到第三方服务等等，GitHub把这些操作称为actions。

工作流含义

在配置好了GitHub仓库之后，一般我们需要再仓库代码中添加一个工作流配置文件，yaml格式，来确定工作流的步骤，其实就是一些列的步骤组成了一个作业。在yaml配置文件中，也可以包含作业运行的基础环境，可以是github提供的原始镜像，也可以用自定义的镜像。在作业执行过程中，就是不断的在镜像相应的容器中执行命令，查看结果。

action marketplace

而且各个步骤一般会用到Action Marketplace，动作市场，可以看为在CI过程中可以使用的一系列动作步骤。

常见的可以包含如下的动作使用：

Checkout
ssh Remote Commands
Build and push Docker images
Setup Python
Publish Test Results
Docker Login
SSH SCP SSH Pipelines
pip-secure-install
文件
- upload-artifact
- download-artifact

示例

功能演示

CI的示例，以项目ActionsPractice为例

在该项目中演示了如下的内容：

Pytest的实践，即在开发过程中开发功能和开发测试
在单元测试的撰写时，演示了为类写测试以及普通的功能函数写测试，以及mock的用法
在CI时使用github提供的环境，使用自定义的镜像

workflow 配置文件

注意，workflow配置文件以yaml为后缀，并且位于.github/workflows

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python

name: Python chenqun-docker application

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read
jobs:
  container-run-test:

    runs-on: [self-hosted, linux, x64, chenqun]
    container:
      image: 10.101.12.128/framework/ubuntu:22.04-official-ali-python3.7.14
      options: --privileged
      
      credentials:
        username: admin
        password: admin@ZJ2023
      volumes:
        - /home/songquanheng:/home/songquanheng
    
    steps:    
    - name: show python version
      run: |
        python --version
    - uses: actions/checkout@v3
    - name: list the files after checkout
      run: | 
        ls -R
    - name: install git
      run: |
        apt-get install -y git

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
    
    - name: Test with pytest and generate coverage report 
      run: |
        pytest --cov=src --cov-report=xml

    - name: Upload coverage reports to Codecov
      uses: codecov/codecov-action@v4
      with:
        token: ${{ secrets.CODECOV_TOKEN }}
        file: coverage.xml
        slug: yanchenmochen/ActionPractice
        verbose: true

网页展示

解释

注意：由于要使用容器环境，因此jobs.job-name.container:下有支持的参数，具体参见

Running jobs in a container
jobs.job-id.container
配置容器启动时的–options参见 Use jobs.<job_id>.container.options to configure additional Docker container resource options. For a list of options, see “docker create options.”

效果

总结

本文详细的记录了为一个GitHub配置一个self-hosted runner的过程，通过上述的过程，我们可以灵活的为仓库配置自定义的运行器，并且也可以使用自定义的容器进行仓库CI作业的执行，提升作业环境的封装性。通过灵活的设计CI工作流的步骤，我们可以方便的设计CI的各个步骤，在执行某个步骤的时候，我们也可以借助于GitHub Actions Marketplace所提供的常用功能组件辅助我们进行有效的工作流配置文件的编写。因此整个生态也是闭包的。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mfbz.cn/a/553078.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！