Allow some unit tests to use object storage for better accuracy

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

During the development of #10586 (closed) we had many issues with our current test-base, relating to uploads. One of the common pattern is that we never test any object storage operation against a real object storage server. We rely on mocking and stubbing.

While this provides for a faster/easier test, we are not really doing a good job with it. Many problems raised during development because we had stub/mock everything, in most cases, mocks and stub were not matching real implementation, and tests were also crafted with the stubs and mocks in mind.

This is a good example of the downsides of mocking. You are not really testing the actual implementation.

Proposal

We should do something similar to what we are doing for Geo and FDW. Because Geo requires an extra database, and that database also requires extra configurations, we flag any test that depends on that with :geo and :geo_fdw. This will be skipped by default when requirements aren't fullfiled (so we don't fail a test because user haven't setup a Geo database or because their database doesn't have FDW support enabled).

Add: :upload_object_storage, :lfs_object_storage, :artifact_object_storage flags. Each one depends on the object storage being enabled for the specific category. When disabled, all tests under it will be skipped automatically. When enabled, we should whitelist WebMock to allow that server to receive requests. We should also provide as part of the default gitlab.yml, a different remote_directory: name for each one under test with a -test suffix, so we don't accidentaly write/delete production data.

Here is one example:

  uploads:
    storage_path: tmp/tests/public
    object_store:
      enabled: false
      remote_directory: uploads-test
      connection:
        provider: AWS # Only AWS supported at the moment
        aws_access_key_id: AWS_ACCESS_KEY_ID
        aws_secret_access_key: AWS_SECRET_ACCESS_KEY
        region: us-east-1
        endpoint: 'http://127.0.0.1:9005'
Edited by 🤖 GitLab Bot 🤖