Github Actions与Docker适配dev/uat/master三分支的自动测试咨询

1. dev分支PR合并前的自动测试校验实现 #

你的需求不存在技术理解偏差，完全可以基于GitHub Actions实现对应校验，核心要注意触发规则的配置逻辑，避免踩文档理解的常见坑：

• 要实现PR发起阶段就触发测试校验，需要将Actions的触发规则配置为pull_request事件，目标分支匹配dev：只要任意开发者发起从个人特性分支指向dev的合并请求，测试流程就会自动启动，不需要等代码合并进dev才触发
• 如果要把测试变成硬性合并门槛，可以在GitHub仓库的分支保护规则中，将对应测试Check设为必须通过的校验项：测试不通过的PR，系统会直接锁死合并按钮，从流程上堵住未测试代码进dev分支的通道
• 常见的配置误区：很多人会把触发规则只配成push到dev分支，这种配置下PR发起时dev分支本身没有收到新提交，测试流程根本不会触发，完全达不到PR阶段校验的效果。可以额外搭配dev分支的push事件触发规则，兜底拦截绕过PR直接推送dev分支的操作。

2. 测试执行环境的行业最佳实践 #

在两种方案都能满足测试要求的前提下，优先用Docker容器承载测试执行环境是目前全球DevOps领域的通用最佳实践，两者的核心差异：

• 直接使用GitHub托管的Ubuntu VM原生环境的问题：VM预装的依赖版本是固定的，后续如果需要安装数据库、缓存等中间件，需要在每次CI运行时手动在VM上部署，安装的版本、配置很容易和本地开发、生产环境出现偏差，最终引发“本地能跑、CI能过、生产故障”的环境一致性问题
• Docker承载测试环境的核心优势：测试用的运行时版本、依赖包版本、中间件版本全部固化在对应的Docker镜像/Compose配置里，CI运行时直接启动和本地完全一致的容器环境执行测试，从根源上消除环境差异的影响
• 特殊适配场景：如果是无外部依赖、单语言运行的极简项目（比如纯静态脚本），直接在VM上通过setup类Action配置对应版本的运行时执行测试也完全可行，不算实践错误，但项目规模增长、引入外部依赖后，这种方案的维护成本会快速上升。

3. 全流程打通的配置逻辑与参考示例 #

整套流程完全可以靠GitHub Actions原生能力实现，不需要额外采购第三方CI工具，链路可以按职责拆分拆解：

• 前置准备：给dev、uat、master三个分支全部开启分支保护，设置为禁止直接推送，所有变更必须通过PR合并，且PR必须通过指定校验项才能合并
• 分阶段流水线配置逻辑：
  • 指向dev的PR：触发轻量校验流程，拉取代码后启动测试容器，执行单元测试、接口冒烟测试，测试通过后自动销毁临时容器
  • 指向uat的PR：在dev的测试流程基础上，执行Docker镜像构建，将镜像推送到镜像仓库，完成后自动部署到UAT环境，触发UAT环境的基础验收巡检
  • 指向master的PR（即UAT验收通过后同步到生产的流程）：在UAT流程的基础上，给构建的镜像打正式版本Tag，完成生产环境部署后，执行生产核心链路的可用性巡检
• 基础测试流程的配置示例（存放路径为.github/workflows/pr-test.yml）：

name: pr-test-check
on:
  pull_request:
    branches: [ dev ]
  push:
    branches: [ dev ]
jobs:
  run-test:
    runs-on: ubuntu-latest
    steps:
      - name: 拉取仓库代码
        uses: actions/checkout@v4
      - name: 启动测试容器并执行用例
        run: docker compose -f docker-compose.test.yml up --abort-on-container-exit --exit-code-from test

上述配置对应的docker-compose.test.yml，就是本地开发时用来跑测试的Compose配置，不需要在GitHub runner的VM上额外安装任何测试依赖。

内容的提问来源于stack exchange，提问作者tpotjj