如何将GitHub Actions工作流变量传入GAE app.yaml配置？

首先需要明确：你之前了解的${{ secrets.DB_URL }}语法，并不是app.yaml原生支持的变量替换逻辑。app.yaml本身是纯静态配置文件，没有内置模板渲染能力——如果没有前置的文件修改步骤，你直接把带这个占位符的app.yaml传给App Engine，平台只会把整个字符串当成环境变量的字面值，根本不会自动关联GitHub的Secrets做替换。你之前见到的可正常工作的配置，本质都是GitHub Actions在部署前，通过脚本把配置里的占位符替换成了实际值，生成了临时版本的配置文件再提交部署的。
你完全不需要为了传MAINTENANCE_MODE去修改GitHub Secrets的配置，这个场景有更轻量的实现方案。

• 改造仓库内的源app.yaml，把写死的内容替换成自定义占位符
  不要在源文件里硬编码MAINTENANCE_MODE的固定值，换成你自己定义的、不会和正常内容冲突的占位符，示例配置：

  runtime: python38
  instance_class: F2
  env_variables:
    DB_URL: "${{ secrets.DB_URL }}"
    MAINTENANCE_MODE: "__MAINTENANCE_VALUE__"
  

• 在GitHub Actions工作流的两个部署环节前，分别做配置值替换
  MAINTENANCE_MODE属于非敏感的流程状态值，根本不需要放到加密的Secrets里存储，直接根据当前工作流的执行阶段，把占位符替换成对应的实际值即可：
  1. 第一次部署（开启维护模式）阶段，把__MAINTENANCE_VALUE__替换成True，部署后线上所有实例重启，读取到维护模式开关打开，就会统一返回503维护页，不连接数据库
  2. 等临时环境里跑完数据库迁移、静态文件收集命令后，第二次部署（关闭维护模式）阶段，把占位符替换成False，部署完成后线上实例恢复正常访问
     对应的工作流核心步骤示例：

  jobs:
    deploy-with-migration:
      runs-on: ubuntu-latest
      steps:
        - name: 拉取仓库代码
          uses: actions/checkout@v4
  
        # 第一次部署：开启维护模式
        - name: 渲染开启维护模式的app.yaml
          run: sed -i "s/__MAINTENANCE_VALUE__/True/" app.yaml
        - name: 部署维护版本到App Engine
          run: gcloud app deploy app.yaml --quiet
  
        # 执行迁移和静态收集（可在临时计算环境完成，不绑定线上服务）
        - name: 执行数据库迁移和静态文件收集
          run: |
            python manage.py migrate
            python manage.py collectstatic --noinput
  
        # 第二次部署：关闭维护模式
        - name: 恢复源app.yaml并渲染关闭维护模式的配置
          run: |
            git checkout app.yaml # 把临时修改的文件恢复成仓库原始版本，避免硬编码状态被提交
            sed -i "s/__MAINTENANCE_VALUE__/False/" app.yaml
        - name: 部署可正常访问的生产版本
          run: gcloud app deploy app.yaml --quiet
  

• 为什么不需要修改GitHub Secrets？
  GitHub Secrets的设计用途是存储长期生效的敏感信息（比如数据库密码、API密钥），而MAINTENANCE_MODE是单次部署流程里临时切换的状态值，生命周期只存在于当前工作流的执行过程中，没有加密存储的必要。哪怕你能通过API修改Secrets的值，也会引入额外的权限配置、状态恢复成本，完全没必要。
• 为什么每次替换完要恢复源app.yaml？
  临时生成的app.yaml里是硬编码的维护模式状态，如果直接提交回仓库，下次正常部署时会因为占位符被替换过，导致配置读取出错，每次部署完用git checkout恢复源文件就能完全规避这个问题。
• 维护模式的页面逻辑怎么落地？
  直接在Django中间件里判断当前环境的MAINTENANCE_MODE变量值，只要值为True，所有请求直接返回503状态和预先写好的维护页HTML，不需要修改平台层的路由配置。

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