GitHub Actions配置RAILS_MASTER_KEY报InvalidMessage加密错误

常见根因及修复方案 #

• 环境变量配置位置或权限错误
  直接在工作流配置里裸写RAILS_MASTER_KEY=${{ secrets.RAILS_MASTER_KEY }}不会被GitHub Actions识别为有效环境变量，必须将变量定义在env块下，支持工作流全局、Job级、Step级三种作用域，Step级配置示例如下：

  - name: Run Rails test cases
    env:
      RAILS_MASTER_KEY: ${{ secrets.RAILS_MASTER_KEY }}
    run: bundle exec rails test
  

  如果是在Docker容器中运行Rails任务，需要额外确认启动容器时已经将该环境变量透传到容器内部；如果Secret是配置在GitHub Environment下而非仓库级Secret，需要在对应Job中添加environment: 你的环境名称配置，否则Job无权读取该环境下的Secret，拿到的变量值为空。

• 存储的Secret值不匹配
  这是Rails版本升级后最高发的问题：

  1. Rails 7升级过程中如果重新执行过rails credentials:edit或加密初始化操作，会生成新的master.key和credentials.yml.enc，如果GitHub仓库Secrets里存的还是Rails 6时期的旧key，必然无法解密。
  2. 复制key到Secrets时容易带入多余的换行、首尾空格，也会导致key校验失败。
     验证方式：将GitHub仓库中存储的RAILS_MASTER_KEY值复制到本地，临时替换本地config/master.key的内容，执行rails credentials:show，如果能正常输出配置内容则key有效，否则需要更新为正确的key值。

• 多环境Credentials加载逻辑不匹配
  Rails 7原生支持分环境的Credentials配置，例如test环境会优先读取config/credentials/test.yml.enc和对应的专属key，如果把ActiveRecord加密配置写在了其他环境的Credentials文件中，test环境下读取不到对应配置也会抛出解密错误。
  可以在测试任务执行前加一行调试命令确认变量是否正常加载（注意不要打印完整key值避免泄露）：

  echo "Loaded RAILS_MASTER_KEY length: ${#RAILS_MASTER_KEY}"
  

  正常合法的master key长度为32位，如果输出长度为0，说明环境变量没有被正确注入到当前执行上下文。

• 加密配置文件未提交到仓库
  确认config/credentials.yml.enc已经被提交到代码仓库，该文件是加密后的配置载体，如果被.gitignore规则拦截没有推送到远端，CI环境拉取到的代码里没有该文件，即使key正确也无法读取配置。注意master.key必须加入.gitignore，不能提交到代码仓库。

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