-
Notifications
You must be signed in to change notification settings - Fork 5
V5.y.z/house keeping #55
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?
Changes from all commits
acdb186
48e8f7c
64888ca
0836f10
43d9deb
dd5f240
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| # Use the LocalStack base image | ||
| FROM localstack/localstack:4.14.0 | ||
| FROM localstack/localstack:2026.05.0 | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The image moves from Prompt To Fix With AIThis is a comment left during a code review.
Path: Dockerfile.localstack
Line: 2
Comment:
**Large LocalStack version jump may affect AWS service emulation**
The image moves from `4.14.0` to `2026.05.0`, which appears to be LocalStack's calendar versioning scheme and represents a very large upstream delta. The integration tests exercise `sns` and `sqs`; any breaking changes in request/response shapes, endpoint behaviour, or error codes would only surface at test time. If the integration test suite passes cleanly with this image, the bump is safe — just worth being aware of the scope of the change.
How can I resolve this? If you propose a fix, please make it concise. |
||
|
|
||
| # Expose the port for LocalStack | ||
| EXPOSE 4566 | ||
|
|
||
This file was deleted.
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.
integration_test_rabbitmqandintegration_test_natshave noif:guard, so they always run on every trigger (including fork pull requests).require_successis therefore the right gate for them. However, if either job is ever given a conditional guard in the future, this call site would need to be upgraded torequire_success_or_skip— unlikeintegration_test, there is no_ENABLEDflag wired here. Worth keeping this asymmetry in mind if the RabbitMQ or NATS jobs are later made optional.Prompt To Fix With AI