-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Fix #1463. Allow to expose multiple ports when running in debug mode #1479
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
* Add ability to specify multiple ports to be exposed from docker instance when running lambda in debug mode * Update and add new tests to verify multiple debug ports
|
|
||
| Success criteria for the change | ||
| ------------------------------- | ||
| All ports (comma separated) specified in ``--debug-port`` SAM CLI parameter should be exposed by docker container. |
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.
Why comma separated? This seems like a good use-case for multiple options: --debug-port 5600 --debug-port 5601.
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.
Good point. Updated with multiple=true option parameter.
jfuss
left a comment
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.
Overall, this looks pretty good. Just a couple requests, nothing major.
| help="When specified, Lambda function container will start in debug mode and will expose this " | ||
| "port on localhost.", | ||
| envvar="SAM_DEBUG_PORT", | ||
| type=click.INT, |
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.
If -d is passed as a string, would this cause any issues? I understand why you would add this but not sure if this affects if the integer was pass as a string ("33333" for example). I want to make sure we don't accidentally break the existing contract here.
I didn't find any specific information on click, but will the debug-port always be a list when passed to our cli methods? I am having a hard time understanding how type in impacts what click will end up passing us.
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.
No issues with passing integer as a string here. Looked to the click parameters type processing logic - it tries to cast a value to integer. Verified it works well with strings unless you specify an invalid value, e.g. "abc" that sounds like an expected behavior.
Looked through click implementation for handling multiple flag - it wraps values into tuple if flag is set and return them or return an empty tuple if no values. So, I would expect we always have tuple after processing --debug-port option. Verified with single and multiple values.
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.
Perfect. Thanks for digging into that.
| at given port inside the container and exposed to the host machine at the same port | ||
|
|
||
| :param int debug_port: Optional, integer value of debug port | ||
| :param list(int) debug_port: Optional, List of integer values of debug ports |
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.
This doc is wrong (was wrong previously). The parameter passed in is debug_options not the debug_port. Could you update this to be correct?
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.
Sure. Fixed doc here and in DebugContext to specify that debug port is a collection of ports to be exposed.
|
|
||
| # container port : host port | ||
| ports_map = {} | ||
| for port in debug_options.debug_port: |
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.
Can you update the docs for debug_options.debug_port to reflect changes to the type?
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.
Done.
| """ | ||
| Initialize the Debug Context with Lambda debugger options | ||
|
|
||
| :param tuple(int) debug_port: Collection of debugger ports to be exposed from a docker container |
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.
Nit: Should this be debug_ports instead of debug_port
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.
Agreed. I thought about the same naming change. My original thought here was to persist the original CLI option --debug-port down to usages. Updated parameter names from InvokeContext down to DebugContext.
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.
Ya we can keep the option the same (--debug-port). This is just an internal object, so no concerns on the updates.
Will do a re-review here shortly.
|
@sdubov I had one last comment. It's purely for readability. Everything else looks good to me. |
- Update DebugContext parameter from "debug-port" to "debug_ports" to make it clear about the implementation details - Update related parameters - Fix the logic to set port when running Java and other containers - Update documentation
01e1044 to
a2b9b05
Compare
|
Not sure why |
|
@sdubov its failing due to a format check. We run a tool called black to make sure everything is formatted the same way throughout the codebase and avoids us having to do things manually. I can pull a update that part tomorrow if you don’t want to set that up. |
|
@jfuss, Thank you for clarifying. No worries. Done with code formatting. |
|
|
||
| debug_port = debug_options.debug_port | ||
| debug_ports = debug_options.debug_ports | ||
| if not debug_ports: |
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.
This check is fine but I think it is not needed. __bool__ on DebugContext is bool(self.debug_ports). This should never execute given the first if statement (if not debug_options).
|
@sdubov Thanks for contributing the feature and going through and addressing all the feedback! |
|
@jfuss, no problem :) thank you for your feedback and a quick review 👍 |
Issue #, if available:
#1463
Description of changes:
Checklist:
make prpassesBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.