-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
APIGW: implement Canary Deployments CRUD logic #12694
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
Conversation
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 17m 54s ⏱️ - 1h 28m 55s Results for commit a3b527a. ± Comparison against base commit 1a9469e. This pull request removes 3343 and adds 8 tests. Note that renamed tests count towards both.
This pull request removes 324 skipped tests and adds 1 skipped test. Note that renamed tests count towards both.
|
Test Results - Alternative Providers597 tests 420 ✅ 14m 40s ⏱️ Results for commit a3b527a. |
Test Results (amd64) - Integration, Bootstrap 5 files 5 suites 2h 23m 12s ⏱️ Results for commit a3b527a. ♻️ This comment has been updated with latest results. |
response = super().update_stage( | ||
context, rest_api_id, stage_name, patch_operations, **kwargs | ||
) | ||
moto_rest_api = get_moto_rest_api(context, rest_api_id) |
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.
note: most of this code is already taken from the parent class, sorry it does not make a clean diff
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.
Wow! Impressive amount of work and testing. 🚀
Thank you for the good PR description, really helpful when diving into some of the changes and weirdness due to the split store! 😬
The list of test and it's coverage is great, the update operation is quite tricky to nail down but you did a great deep dive here. Looking forward to see the follow up with invocation changes! 🥳
Motivation
We've got a request to support Canary Deployments CRUD logic as it is needed in some Terraform deployments.
This was on a radar for a while, and there was no support for it in Moto.
This PR only implements the CRUD support for it, a follow-up PR will implement the actually canary deployments logic during invocation, with the ability to direct requests to either deployment. The test for it is already in this PR just to verify how it worked in AWS (with
test_invoking_canary_deployment
).I'm conscious that this implementation is... not great. There are so many patches, the update logic is really complex. Those JSON Patches really don't make this easy. We should probably rework some kind of framework to easily handle validation + application of those.
At first, I didn't want to duplicate the code, and I couldn't insert it from the child class inside
update_stage
. I had done in the legacy provider, but I don't want to break existing things and have partial things implemented so I moved it back to the next gen/current provider. This would have made the diff simpler, sorry!The logic implemented is documented in AWS here: https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html
There was also a bug in Moto where it would update your stage deployment id to the one of the canary setting if you were to set one due to greedy check.
note: test failure is a flake in DDB Streams
Changes
CreateStage
,UpdateStage
,CreateDeployment