spatie/laravel-google-cloud-storage is not compatible with Laravel versions greater than 8, which currently blocks https://phabricator.wikimedia.org/T341796
As we need to migrate anyways now, let's choose sth S3 compatible instead so that we can also use these features in our local setup. S3 seems to be supported by Laravel itself, so we don't even need to hunt for a new dependency.
We discussed in the daily that it would be acceptable to break the logo upload feature for the time being, but this should also be reflected in the UI (by disabling the option, so users don't run into an mysterious error when we already know it is "intentionally" broken.
Here's a quick patch disabling the logo card with a message: wbstack/ui/pull/762 | Temporarily disable custom logo feature
@Charlie_WMDE please let me know here if you're happy with both the design and text: https://2a4448cdd3-prod--wbstack-ui.netlify.app/
We discussed how temporarily breaking this feature might be useful in order to at least drive forwards the laravel 9 update and get us out of the catch 22 of how can we move to Uniform Bucket Level Access
As I understand it we may be able to avoid that entirely by understanding and fixing the permissions on the bucket so that that the API is free to do what it wants to with the ACLs and then in the future move to Uniform Bucket Level Access; this is what the two PRs currently up for review strive towards.
I'm totally happy for us to go either way or even to not strive for unified bucket ACLs in the future. I'm very happy, given we even have a nice UI change for it, to temporarily break either the uploading or the actual display of logos for wikis.
My only real concerns are that:
There is nothing broken here. If we set the ACLs as in https://github.com/wbstack/api/pull/727, images will have the desired visibility. Fixing the permissions from https://github.com/wmde/wbaas-deploy/pull/1366#pullrequestreview-1833365350 is relatively simple and should not keep us from shipping anything.