Uma reflexão a partir disso: modelos de compatibilidade temporários como este podem ser mais seguros se tiverem algum tipo de condição de autoexpiração/guarda, em vez de continuar sobrescrevendo as dependências do Discourse indefinidamente.
Por exemplo, com backports temporários de código-fonte, estou planejando usar hooks em produção que primeiro verifiquem se a correção upstream já está presente e apliquem o patch apenas se ainda for necessário.
Neste caso, algo ao longo dessas linhas poderia potencialmente ter impedido que o pin antigo aws-sdk-s3 1.177.0 continuasse uma vez que o próprio Discourse começou a depender de funcionalidades mais novas do SDK:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse agora requer Aws::S3::TransferManager; pulando o downgrade obsoleto do aws-sdk-s3 do Backblaze"
else
echo "Aplicando pin temporário de compatibilidade do aws-sdk-s3 do Backblaze"
bundle config set frozen false
sed -i 's/gem "aws-sdk-s3", require: false/gem "aws-sdk-s3", "1.177.0", require: false/' Gemfile
bundle update aws-sdk-s3
bundle add aws-sdk-core --version 3.215
fi
Essa verificação específica é apenas ilustrativa - uma verificação de versão mais geral ou uma falha explícita quando o Discourse passar da versão de SDK esperada provavelmente seria melhor.
Mesmo falhar de forma explícita seria provavelmente preferível a silenciosamente produzir um container cujos gems não correspondem mais às versões esperadas pelo Discourse.