想在 Ubuntu 上把 Golang 项目的测试、编译和发布流程自动化，常见做法是先搭一条最小可用的 CI 流水线。下面就以 GitHub Actions 为例，从本机环境、工作流文件到镜像推送条件逐步展开，方便你判断这套方案是否够用，以及后续该往哪里扩展。
先把 Ubuntu 上的 Go 构建环境补齐
安装基础工具
在开始配置持续集成之前，先确认 Ubuntu 上已经具备最基本的开发和构建工具。文中给出的组合包括：
- Git
- Go
- Docker（可选，如果后续要构建容器镜像）
可以直接执行下面的命令完成安装：
sudo apt update
sudo apt install git golang docker.io如果你当前只需要自动测试和编译二进制，Docker 不是必选项；但只要准备在 CI 中顺手产出镜像，提前装好会更省事。
配置 Go 环境变量
Ubuntu 上的 Go 环境变量至少要理顺 GOROOT、GOPATH 和可执行文件搜索路径，否则本地调试和 CI 对齐时容易出现环境差异。
可直接在终端执行：
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin如果不想每次登录都重复输入，建议把这几行追加到 ~/.bashrc 或 ~/.profile。这样一来，本地构建环境会更稳定，也更方便排查 CI 与开发机之间的差异。
先把代码放进 GitHub 仓库
GitHub Actions 是围绕仓库事件触发的，所以前提是你的 Golang 项目已经托管到 GitHub。若仓库还没创建，先新建一个仓库并把代码推上去；这一步虽然简单，但它决定了后面的工作流能否按 push 和 pull_request 事件自动运行。
用 GitHub Actions 建立自动测试与打包流程
创建工作流文件
在项目根目录下创建 .github/workflows 目录，并写入一个工作流文件，例如 ci.yml。原始示例如下：
name: CI and Build
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.17
- name: Run tests
run: go test ./...
- name: Build binary
run: go build -o myapp
- name: Create Docker image (optional)
if: github.ref == 'refs/heads/main'
run: |
docker build -t myapp .
docker login -u ${{ secrets.DOCKER_HUB_USERNAME }} -p ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}
docker push myapp这份配置对应的是一条很典型的基础流水线，核心步骤包括：
- 拉取仓库代码：
actions/checkout@v2 - 安装并切换 Go 版本：
actions/setup-go@v2，示例中使用go-version: 1.17 - 执行测试：
go test ./... - 编译二进制文件：
go build -o myapp - 仅在
main分支上构建并推送 Docker 镜像
如果你的目标只是先把测试和编译自动化，这个模板已经够用；后续要加代码扫描、覆盖率统计或多平台构建，也都可以从这一版继续扩展。
理解 Docker 步骤为什么只放在 main 分支
示例里最需要注意的一点，是镜像构建和推送步骤带了这条条件：
if: github.ref == 'refs/heads/main'这意味着工作流虽然会在 push 和 pull_request 时触发，但 Docker 镜像并不会在所有场景下都推送。这样做的好处很直接：既能保证每次提交都会测试和编译，又能避免功能分支或临时代码把镜像仓库刷乱。
需要推送镜像时，别漏掉 Secrets 配置
如果你打算在 CI 里构建 Docker 镜像，还需要提前准备好 Docker Hub 账号，或者其他镜像注册表的认证信息。
按照原文示例，至少要在 GitHub 仓库的 Secrets 中添加两个变量：
DOCKER_HUB_USERNAMEDOCKER_HUB_ACCESS_TOKEN
工作流中的登录命令如下：
docker login -u ${{ secrets.DOCKER_HUB_USERNAME }} -p ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}如果这两个值没有提前配置，流水线在推送镜像时就会直接报错。对很多初次上手 GitHub Actions 的项目来说，这一步往往比 YAML 语法本身更容易遗漏。
提交工作流后，流水线会自动触发
工作流文件写好后，把它提交并推送到 main 分支即可：
git add .github/workflows/ci.yml
git commit -m "Add CI and Build workflow"
git push origin main只要仓库事件和分支条件匹配，GitHub Actions 就会自动启动，不需要再手动执行额外命令。
到 Actions 页面查看结果与排错
推送完成后，可以直接打开仓库的 Actions 标签页查看运行状态。这里通常能看到每一步是否成功执行，以及失败时的详细日志。
对于这条基础流水线来说，排查时可以重点关注几个节点：
- Go 版本是否按
1.17正确安装 go test ./...是否因为依赖、路径或测试失败中断go build -o myapp是否成功产出二进制文件- Docker 登录和
docker push myapp是否因 Secrets 缺失而失败
如果只是想先确认 CI 能不能跑通，这个页面就是最直接的判断依据。
这套基础方案适合先跑通，再逐步加料
按上面的步骤配置后，一个面向 Ubuntu 环境的 Golang 基础持续集成与打包流程就搭好了：提交代码即可自动测试、自动编译，必要时还能在 main 分支上顺带推送 Docker 镜像。
这套配置的价值在于足够简单、容易验证，也方便继续扩展。后续如果项目要求更高，可以在现有工作流上继续加入代码质量扫描、性能测试、跨平台交叉编译等能力。
