feat: Support for comma-separation and ranges in port-forward #4166
Conversation
|
Please, also update the docs with all example cases. |
|
@matifali any thoughts on an example that would be most helpful? Currently we show one and defer to |
How about this? |
|
|
| type parsedSrcDestPort struct { | ||
| local, remote uint16 | ||
| } |
There was a problem hiding this comment.
Why not just have the function return a portForwardSpec directly? You could pass it a listen and dial network and it would return []portForwardSpec instead of having an intermediary type
There was a problem hiding this comment.
My thinking was probably influenced by the previous implementation, and keeping the type "plain until use". Why plain? For instance, if you see the test where we mangle the portForwardSpec to make testing more convenient, that's not ideal IMO. In fact I could see parsePortForwards returning []parsedSrcDestPort if it was updated with protocol string field. Then all items could be post-processed into portForwardSpec as a last step ¯\_(ツ)_/¯. That code would seem more re-usable if we ever want to parse the port format in other places.
I'm not married to this by any means, I can change it, but I don't see a clear benefit to either way of doing it.
This PR adds support for a more condensed port-forwarding syntax (e.g.
--tcp 8080,9000-9010,9990-9999:10990-10999).Tests implemented as an internal test since testing the effect (multiple port ranges) isn't feasible externally.
Fixes #3766