One thought from this: temporary compatibility templates like this may be safer if they have some kind of self-expiring/guard condition, rather than continuing to override Discourse dependencies indefinitely.
For example, with temporary source backports, i’m planning to use hooks in production that first check whether the upstream fix is already present, and only apply the patch if it is still needed.
In this case, something along these lines could potentially have prevented the old aws-sdk-s3 1.177.0 pin from continuing once Discourse itself started depending on newer SDK functionality:
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- |
if grep -q "Aws::S3::TransferManager" lib/s3_helper.rb; then
echo "Discourse now requires Aws::S3::TransferManager; skipping obsolete Backblaze aws-sdk-s3 downgrade"
else
echo "Applying temporary Backblaze aws-sdk-s3 compatibility pin"
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
That particular check is just illustrative - a more general version check or an explicit failure when Discourse moves past the expected SDK version would probably be better.
Even failing loudly would likely be preferable to silently producing a container whose gems no longer match the versions expected by Discourse.