Sobre a atualização da fonte do Discourse, dependências de nível de sistema operacional, a imagem base do Docker, gems do Ruby e afins, é possível fazer isso realizando a build em duas etapas e executando as tarefas mencionadas na primeira etapa.
Essa primeira etapa é independente do ambiente e pode ser executada até mesmo em um ambiente de CI (assim, você pode usar uma imagem quase idêntica nos ambientes de staging e produção, evitando possíveis erros decorrentes de rebuilds em datas diferentes, sem falar na redução do tempo de inatividade).
As tarefas de migração do banco de dados e assets:precompile ainda precisariam ser executadas na máquina de destino. A migração do banco de dados, na maioria dos casos, seria rápida. Por outro lado, a tarefa assets:precompile é um problema porque é a etapa que mais consome tempo. Acredito que isso ocorra porque alguns ativos precisam conhecer certas configurações do ambiente definidas no banco de dados, como algumas regras CSS, para serem executados.
Seria extremamente útil se essa tarefa fosse dividida em duas partes: primeiro, todos os ativos que não dependem do ambiente seriam compilados e poderiam ser executados em um ambiente de CI; e, na segunda etapa, seriam compilados apenas os ativos que dependem de dados do banco de dados, etc. Dito isso, não sei quão difícil seria, tecnicamente, implementar isso.
Discuto sobre o bootstrap do contêiner do aplicativo em duas etapas no seguinte tópico:
As alterações que fiz foram apenas sobre dividir o template web do Discourse em três arquivos, mas as tarefas permanecem as mesmas. No entanto, seria ótimo se a equipe do Discourse desse suporte a isso, para que eu não precisasse atualizá-las devido a futuras alterações no template web.