我也没有看到解决方案。另一种方法是继续设置config/environments/production.rb，使其包含以下行：
config.require_master_key = false
并继续使用SECRET_KEY_BASE=1 rails assets:precompile
我还没有找到更好的方法。至少这种方法看起来比维护一个假的万能钥匙要好。

我对此的解决方案（Rails6+）是为每个env（测试、开发、生产）提供单独的凭证文件。
运行测试时，我通过RAILS_MASTER_KEY=xxx向CI提供test环境的解密密钥。要使用RAILS_ENV=production预编译资产，我只需将测试凭据YML文件复制到生产凭据之上。然后，资产步骤只需使用test环境密钥即可解密凭据。

echo "Using 'test' environment credentials for precompiling"
cp ./config/credentials/test.yml.enc ./config/credentials/production.yml.enc

echo "Compiling assets"
RAILS_ENV=production bundle exec rake assets:precompile

我创建了一个假的凭据。yml.enc和与之关联的RAILS_MASTER_KEY，并在预编译资产时使用它们。

我们可以在Docker 1.13和更高版本中轻松解决该问题（假设您的配置项也在Docker容器中运行），方法是使用Docker机密将 master.key 传递到配置项容器。请注意，这仅在Docker群中有效，但单个Docker容器也可以充当Docker群节点。要更改单个节点（例如，在本地开发系统上）添加到群节点，使用 init 命令并按照说明操作：

docker swarm init

https://docs.docker.com/engine/reference/commandline/swarm_init/
然后，在CI容器的 * docker-composite.yml* 中，将 master.key 声明为docker secret，并将其**定位到容器中的正确位置：

version: '3.4'

services:
  my_service:

    ...  

    secrets:
    - source: master_key
      target: /my_root/config/master.key
      uid: '1000'
      gid: '1000'
      mode: 0440

    ...  

    security_opt:
    - no-new-privileges

    ...  

secrets:
  master_key:
    file: config/master.key

https://docs.docker.com/compose/compose-file/
如您所见，我们还可以为容器中的 master.key 分配专门的访问权限，并保护它不受权限提升的影响。有关Docker Swarm的进一步说明，请访问：
https://docs.docker.com/engine/swarm/secrets/#how-docker-manages-secrets
为什么这应该是解决问题的首选方案？您的秘密 master.key 不再存储在CI Docker容器中，而是安全地保存在Docker Swarm基础设施的加密Raft日志中，您不必使用假密钥进行任何杂技般的扭曲。
顺便说一句，我使用这种方法来保护我在公共Docker容器中的特定于领域的专业知识：使用 target 参数，每个Docker secret可以携带最大为500 kb的通用字符串或二进制内容，尤其是包含敏感知识的代码段。