-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
LocalStack SDK for integration tests #12991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
S3 Image Test Results (AMD64 / ARM64) 2 files 2 suites 8m 25s ⏱️ Results for commit 30cee15. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 2h 20m 36s ⏱️ Results for commit 30cee15. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While it is intriguing to use the SDK directly here to test the features of LocalStack that are exposed via the SDK, I think we have to be very careful with dependencies like this.
Let's discuss this a bit more in depth before introducing this dependency! :)
@@ -116,6 +116,7 @@ test = [ | |||
"aws-cdk-lib>=2.88.0", | |||
"websocket-client>=1.7.0", | |||
"localstack-snapshot>=0.1.1", | |||
"localstack-sdk-python" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: This effectively implements a circular dependency:
- The SDK is directly generated from the OpenAPI specs.
- The OpenAPI specs are released with every release of LocalStack Pro.
- The SDK is defined as a dependency of LocalStack Pro's test dependencies here.
In my opinion, this could make it very much more tedious to implement changes when changing the API endpoint or adding new ones.
But what exactly is the motivation behind using the SDK here directly?
- Is it to save some lines of code? Maybe we should then restructure the code or the API to make sure the API is very easily usable.
- Or is it to verify that the SDK works? I think that should be verified directly in the repo of the SDK. If you want to do regular integration tests, you could run a scheduled integration test pipeline there, ensuring that the latest SDK still integrates well with latest?
Motivation
In #12972 @viren-nadkarni suggested using the LocalStack SDK for our own integration tests.
Changes
This PR:
localstack-sdk-python
to our test dependencies;