Problem/Motivation
At the moment the majority of test files do not function inside of Drupal CI due to the need for secrets and a real S3 bucket, these tests return a SKIP results which is treated as a PASS.
Steps to reproduce
Proposed resolution
Add a method, possibly a localstack docker image or similar, that would allow S3 to execute functional tests in the Drupal CI environment.
Remaining tasks
User interface changes
API changes
Data model changes
Issue fork s3fs-3206493
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
cmlara#3134530: cURL error (60) SSL certificate problem: self signed certificate would make this easier, we could get around this by creating images and importing self signed CA certs into the docker images however that could require long term maintenance against the images.
Comment #3
jonathanshawCommerce_stripe's tests/src/FunctionalJavascript/CheckoutTest.php is testing against the real stripe API, although that's not obvious when you look at it. I know because it keeps failing when stripe changes their API ;)
Comment #4
cmlaraAh I think I see it now, thanks for the re-point. I see where they put a secret key in, and realize now that those commands likely still execute form submissions which Drupal will process using said key so that makes more sense.
Looks like stripe has a nice well designed system with production keys and test keys. I'm still not sure I could do similar with S3 at the moment. I can't lock it down by IP as its all of the EC2 cloud for the build bots. Even if i still can lock a bucket down to only a few files and sizes I believe it would still be a risk for attacking if published so I'm still inclined to go with the companion docker image approach unless I hit a significant fault. Also a bonus of not having possible build contention of two builds trying to test at the same time against the same real bucket (highly unlikely but with my luck it would happen)
And a note to correct previous post: I don't believe we actually need #3134530: cURL error (60) SSL certificate problem: self signed certificate for this. At first I was thinking I would need the docker network to route the S3 AWS domain to the image (which would create an invalid cert check) but realized this morning "the only test that really required we not set a custom endpoint was the getBucketRegion portion of config validation, and that won't work against localstack anyways" beyond that we can use the http endpoint for testing on a local network.
Comment #7
cmlara