Une réflexion à ce sujet : des modèles de compatibilité temporaire comme celui-ci seraient peut-être plus sûrs s’ils étaient dotés d’une condition d’auto-expiration ou de garde-fou, plutôt que de continuer à écraser indéfiniment les dépendances de Discourse.
Par exemple, pour les rétroportages de code source temporaires, je prévois d’utiliser des hooks en production qui vérifient d’abord si le correctif amont est déjà présent, et n’appliquent le correctif que s’il est encore nécessaire.
Dans ce cas, une logique de ce type aurait potentiellement pu empêcher le maintien de l’épinglage de aws-sdk-s3 1.177.0 une fois que Discourse lui-même a commencé à dépendre de fonctionnalités plus récentes du SDK :
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse nécessite désormais Aws::S3::TransferManager ; on saute le downgrade obsolète de aws-sdk-s3 pour Backblaze"
else
echo "Application de l'épinglage temporaire de compatibilité aws-sdk-s3 pour 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
Cette vérification particulière n’est qu’illustrative — une vérification de version plus générale ou un échec explicite lorsque Discourse dépasse la version de SDK attendue serait probablement préférable.
Même un échec bruyant serait probablement préférable à la production silencieuse d’un conteneur dont les gems ne correspondent plus aux versions attendues par Discourse.