Ein Gedanke dazu: Temporäre Kompatibilitätstemplates wie dieses wären möglicherweise sicherer, wenn sie eine Art von selbstlöschender oder schützender Bedingung aufweisen, anstatt die Abhängigkeiten von Discourse dauerhaft zu überschreiben.
Zum Beispiel plane ich bei temporären Quellcode-Backports, in der Produktion Hooks zu verwenden, die zunächst prüfen, ob der Upstream-Fix bereits vorhanden ist, und das Patch nur dann anwenden, wenn es noch benötigt wird.
In diesem Fall hätte etwas in dieser Form möglicherweise verhindert, dass das alte aws-sdk-s3 1.177.0-Pinning fortbesteht, sobald Discourse selbst von neueren SDK-Funktionen abhängt:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse benötigt jetzt Aws::S3::TransferManager; überholtes Backblaze aws-sdk-s3-Downgrade wird übersprungen"
else
echo "Temporäre Backblaze aws-sdk-s3-Kompatibilitäts-Pinning wird angewendet"
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
Dieser spezifische Check ist nur beispielhaft – eine allgemeinere Versionsprüfung oder ein expliziter Fehlerfall, wenn Discourse die erwartete SDK-Version überschreitet, wäre wahrscheinlich besser.
Selbst ein lautes Scheitern wäre wahrscheinlich vorzuziehen, als stillschweigend einen Container zu erzeugen, dessen Gems nicht mehr mit den von Discourse erwarteten Versionen übereinstimmen.