背景

几年前开始，为了将自己的杂七杂八的代码托管起来，自己建了代码私服，当时综合调研了下选择了比较轻量的Gitea，一是防止github、gitee、coding等产品托管的代码审查，二是为了应对墙，不然推送代码真吃力，三是自己管理代码还是简单的压缩，出现了多个版本的压缩包，重复又难看。

前段时间 Gitea 发布了1.22.0版本，Gitea Actions成为了内置的CI/CD解决方案已经有一段时间了，所以打算慢慢迁移到Gitea Actions，这样可以统一维护，再加上Drone被收购后产品路线也发生了一些变化，所以打算迁了。（目前docker安装的1.23.3）

尽管Gitea Actions旨在与GitHub Actions兼容，但它们之间存在一些差异，但是Gitea Actions目前没有什么详情的语法文档，所以本文主要通过学习Github Actions，差异可以根据Gitea 文档进行微调，一下掌握两个平台的使用，当然也可以举一反三应用到其他CI/CD平台，只是编写yml语法不同，原理都是大差不差。

概念

GitHub Actions 是一种持续集成和持续交付 (CI/CD) 平台，可用于自动执行生成、测试和部署管道。您可以创建工作流程来构建和测试存储库的每个拉取请求，或将合并的拉取请求部署到生产环境。

GitHub Actions 不仅仅是 DevOps，还允许您在存储库中发生其他事件时运行工作流程。例如，您可以运行工作流程，以便在有人在您的存储库中创建新问题时自动添加相应的标签。

GitHub 提供 Linux、Windows 和 macOS 虚拟机来运行工作流程，或者您可以在自己的数据中心或云基础架构中托管自己的自托管运行器。

Gitea 也是如此，只是Gitea Runner需要自己注册，可以根据自己手里的机器直接注册。

大白话讲：就是当你的代码仓库发送某种变化时，你要触发某种工作流，然后进行编排自动执行。举个栗子：当你推送代码到仓库后，需要验证多个平台是否都能正常编译运行，都通过之后就发布到内部测试环境供测试人员进行测试，如果没有通过就不执行发布流程等等，这样就可以从传统开发本地打包再手动部署服务器上，然后启停服务，再验证服务是否正常这么复杂的流程。

准备环境

可以直接采用公有云Github创建一个公开仓库进行学习，当然你也可以按照 Gitea 官方安装手册自己部署示例进行练习。

github 准备一个空仓库，新建 .github/workflows/ci-demo.yml 文件，
gitea则新建 .gitea/workflows/ci-demo.yml

编写一个简单的配置文件，示例如下：

name: GitHub Actions Demo
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 }}."

建一个私人的 test 空仓库。
点进去再点 actions，建立自定义workflow如下命名和粘贴就行。最后右上角commit提交

上方是一个示例demo，github actions默认是自动开启，使用gitea actions则需要按照 手动启用仓库actions ，当你推送文件到仓库时候，就会自动执行了。

github actions运行截图：仓库导航 -> Acitons -> 左侧导航All workflows -> 查看Explore-GitHub-Actions -> 点击查看详情

gitea则直接创建空仓库test后点击代码新建文件后提交。

gitea actions运行截图：仓库导航 -> Acitons -> 左侧导航所有工作流 -> 点击查看详情

这里的没有runner在线，是因为我们只部署了gitea，没有配置gitea action，可以部署一个Act-Runner，参考教程：
https://b.voiceclouds.cn/archives/pveazgitearunner

确认有了runner后，

github actions运行截图：仓库导航 -> Acitons -> 左侧导航All workflows -> 查看Explore-GitHub-Actions -> 点击查看详情

就是正常的了。

以上步骤运行成功，说明你的环境没有任何问题，可以继续往下学习了。

常用组件名词解释

Workflows(工作流程)

工作流程是一个可配置的自动化过程，它将运行一个或多个作业。工作流程由签入到存储库的 YAML 文件定义，并在存储库中的事件触发时运行，也可以手动触发，或按定义的时间表触发。

工作流程在存储库的【github】.github/workflows 或者【gitea】 .gitea/workflows 目录中定义，存储库可以有多个工作流程，每个工作流程都可以执行不同的任务集。例如，您可以有一个工作流程来构建和测试拉取请求，另一个工作流程用于在每次创建发布时部署应用程序，还有一个工作流程在每次有人打开新议题时添加标签。

Events(事件)

事件是存储库中触发工作流程运行的特定活动。例如，当有人创建拉取请求、打开议题或将提交推送到存储库时，活动可能源自 GitHub。此外，还可以通过回调api或者手动方式触发工作流按计划运行。

Jobs(任务)

作业是工作流中在同一运行器上执行的一组步骤。每个步骤要么是一个将要执行的 shell 脚本，要么是一个将要运行的动作。步骤按顺序执行，并且相互依赖。由于每个步骤都在同一运行器上执行，因此您可以将数据从一个步骤共享到另一个步骤。例如，可以有一个生成应用程序的步骤，后跟一个测试已生成应用程序的步骤。

您可以配置作业与其他作业的依赖关系；默认情况下，作业没有依赖关系，并且彼此并行运行。当一个作业依赖于另一个作业时，它将等待从属作业完成，然后才能运行。例如，对于没有依赖关系的不同体系结构，您可能有多个生成作业，以及一个依赖于这些作业的打包作业。生成作业将并行运行，当它们全部成功完成后，打包作业将运行。

Steps(步骤)

步骤，某个任务下的多个步骤。步骤可以是操作，也可以是 shell 命令。作业中的每个步骤都在同一个运行程序上执行，从而允许该作业中的操作彼此共享数据。

Actions(操作)

操作是用于 GitHub Actions 平台的自定义应用程序，它执行复杂但经常重复的任务。使用操作可帮助减少在工作流程文件中编写的重复代码量。操作可以从 GitHub 拉取 git 存储库，为您的构建环境设置正确的工具链，或设置对云提供商的身份验证。

您可以编写自己的操作，也可以在 GitHub Marketplace 中找到要在工作流程中所有可以使用的操作

Runners(运行器)

运行程序是触发工作流时运行工作流的服务器。每个运行器一次可以运行一个作业。 GitHub 提供 Ubuntu Linux、Microsoft Windows 和 macOS 运行器来运行您的工作流程；每个工作流程运行都在新预配的全新虚拟机中执行。 GitHub 还提供大型运行器（适用于大型配置）。如果需要其他操作系统或特定硬件配置，可托管自己的运行器。

了解工作流配置文件

我们拿前面的ci-demo.yml工作流程来说明一下：

name: GitHub Actions Demo # 可选 - 工作流程的名称，它将显示在 GitHub 存储库的“操作”选项卡中。如果省略此字段，则将使用工作流程文件的名称
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀 # 工作流生成的工作流运行的名称，Gitea本文编写时暂时不支持
on: [push] # 指定此工作流的触发器。此示例使用 push 事件，因此每次有人将更改推送到存储库或合并拉取请求时都会触发工作流运行。这是由对每个分支的推送触发的；有关仅在推送到特定分支、路径或标签时运行的语法示例，请参阅“GitHub Actions 的工作流语法”。
jobs: # 工作流程中运行的所有作业job聚合在一起。
  Explore-GitHub-Actions: # 定义一个名为 Explore-GitHub-Actions 的作业job。下面则将定义作业的属性。
    runs-on: ubuntu-latest # 将作业配置为在最新版本的 ubuntu-latest 运行程序上运行。这意味着该作业将在 GitHub 托管的新虚拟机上执行。
    steps: # 作业中运行的所有操作聚合在一起。
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." # run 关键字告诉作业在运行器上执行命令。 下面也同样的。
      - 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 # name关键字设置操作步骤的名称，界面上流程会展示出来
        uses: actions/checkout@v4  # 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 }}."

GitHub Actions 的工作流语法：https://docs.github.com/zh/actions/using-workflows/workflow-syntax-for-github-actions#run-name

知道每个步骤的写法，我们可以参考官方语法自己定义手写一个：有两个job，job2依赖job1，job1使用ubuntu，job2使用windows

name: test ci
run-name: test run name
on:
  push:
    branches:
      - master
jobs:
  job1:
    runs-on: ubuntu-latest
    steps:
      - name: 步骤1
        run: ls -lh
      - name: 步骤2
        run: |
          pwd
          date
      - name: 步骤3：检出代码
        uses: actions/checkout@v4
      - name: 步骤4
        run: |
          ls -lh
          date
  job2:
    needs: [job1]
    runs-on: windows-latest
    steps:
      - name: job2步骤1
        run: git version

在github上测试了，因为本地nas的gitea目前只有一个runner（ubuntu）就不测试了。

后面再慢慢学习吧。

后记

如果只是存储代码。可能不需要runner去测试，runner大致是为了在github上用于流程打包发布版本，编译所用的一个虚拟机（linux，macos，win等等都是不同的runner）。

暂未测试runner本地的docker大概占用多少资源，占用多的话，我也打算关掉它。

生生不息