推代码就上线：GitHub Actions 自动发版 Docker 镜像

每次改完代码，手动 docker build、登录、打 tag、push、再上服务器拉新镜像——这套动作重复十几次之后，谁都会烦。我把这条链路交给了 GitHub Actions：push 到 main 就自动构建镜像并推到仓库，部署那步也可以顺带触发。记录一下这个最精简可用的 workflow。

一、手动打包太累了

重复劳动最大的问题不是费时，而是容易出错：tag 打错、忘了 push、登录凭据写错，每次都重新踩一遍。CI 的好处是把"怎么做"固化成文件，跑一百次都一致。GitHub Actions 直接集成在仓库里，不用另搭服务器，对小项目零成本。

二、workflow 文件这样写

在 .github/workflows/build.yml：

name: build-and-push
on:
  push:
    branches: [main]

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Log in to registry
      run: echo "${{ secrets.DOCKER_PWD }}" | docker login -u ${{ secrets.DOCKER_USER }} --password-stdin

    - name: Build and push
      run: |
        docker build -t myrepo/app:${{ github.sha }} .
        docker push myrepo/app:${{ github.sha }}

github.sha 是这次提交的哈希，当镜像 tag 既唯一又可追溯。 secrets 里配好 DOCKER_USER / DOCKER_PWD，凭据不落代码。

三、密钥和缓存

latest 虽方便但难回滚，生产推荐不可变 tag，出问题按 sha 精准退版本。

四、过程中的几个易错点

• 没给仓库开 Actions 权限：新仓库默认可能不让写包，要在仓库设置里确认 Workflow 权限为可读写。
• secret 名字拼错：${{ secrets.DOCKER_PWD }} 和设置里的 key 必须一字不差，否则登录静默失败。
• Dockerfile 没缓存层：依赖安装写在源码 COPY 之后，每次改一行代码都重装依赖，构建巨慢。把依赖先 COPY 再装，利用层缓存。

总结

把"构建+推送镜像"交给 GitHub Actions，等于给发布流程上了一道保险：每次提交都是一次标准发版，不再依赖某个人记得步骤。等这条稳定了，再在后面加一个 SSH 部署或调 Webhook 的步骤，就能做到"推代码即上线"。CI 的精髓不是炫技，是把重复动作变成可信赖的自动化。