Un pensiero in merito: i modelli di compatibilità temporanei come questo potrebbero essere più sicuri se dotati di una sorta di condizione di auto-scadenza o di protezione, anziché continuare a sovrascrivere le dipendenze di Discourse all’infinito.
Ad esempio, per i backport temporanei del codice sorgente, ho in programma di utilizzare hook in produzione che prima controllino se la correzione upstream è già presente e applichino la patch solo se è ancora necessaria.
In questo caso, qualcosa di simile avrebbe potuto potenzialmente impedire che il pin di aws-sdk-s3 1.177.0 rimanesse attivo una volta che Discourse stesso ha iniziato a dipendere da funzionalità più recenti dell’SDK:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse ora richiede Aws::S3::TransferManager; salto il downgrade obsoleto di Backblaze aws-sdk-s3"
else
echo "Applico il pin temporaneo di compatibilità Backblaze aws-sdk-s3"
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
Quel controllo specifico è solo esemplificativo: una verifica di versione più generale o un errore esplicito quando Discourse supera la versione SDK prevista sarebbero probabilmente preferibili.
Anche un errore esplicito sarebbe probabilmente preferibile rispetto alla generazione silenziosa di un container i cui gem non corrispondono più alle versioni attese da Discourse.