Una reflexión sobre esto: las plantillas de compatibilidad temporal como esta podrían ser más seguras si incluyen algún tipo de condición de autoexpiración o de protección, en lugar de seguir sobrescribiendo las dependencias de Discourse de forma indefinida.
Por ejemplo, con los backports temporales de código fuente, planeo usar hooks en producción que primero comprueben si la corrección ya está presente en la versión upstream y solo apliquen el parche si aún es necesario.
En este caso, algo a lo largo de estas líneas podría haber impedido que el pin fijo de aws-sdk-s3 1.177.0 continuara una vez que Discourse empezó a depender de funcionalidades más nuevas del SDK:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse ahora requiere Aws::S3::TransferManager; omitiendo la degradación obsoleta de aws-sdk-s3 de Backblaze"
else
echo "Aplicando pin de compatibilidad temporal de aws-sdk-s3 de 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
Esa comprobación en particular es solo ilustrativa; una comprobación de versión más general o un fallo explícito cuando Discourse supere la versión de SDK esperada probablemente sería mejor.
Incluso fallar de forma explícita sería preferible a generar silenciosamente un contenedor cuyos gem ya no coincidan con las versiones esperadas por Discourse.