Repository navigation
Conversation
| argPort, | ||
| defaultsTo: '9100', | ||
| abbr: 'p', | ||
| // ChromeOS exposed ports: 8000, 8008, 808, 8085, 8888, 9005, 3000, 4200, 5000 |
There was a problem hiding this comment.
remove the comment about the ports allowed on chromeos?
| break; // Don't try any more if we bound one. | ||
| } on SocketException catch (e) { | ||
| printOutput( | ||
| 'Unable to bind to port $port: $e', |
There was a problem hiding this comment.
only show this message if binding to all ports fail?
There was a problem hiding this comment.
never mind. this is fine.
|
Holding off on merging this for now - as well as conflicting with @kenzieschmoll's other PR, I think there may be other blockers to running on CrOS in this way (we'd need the VM and Flutter to have some equivalent of this). |
|
Haven't forgotten about this - just unclear if we'll need it now (and it doesn't make sense to land if we won't use it). If it's not clear we'll use it soon, I'll just close it. |
|
There's a better solution on the way, so for now we're just going to use a single hard-coded port and don't need this. |
2 participants
This extends the
--portoption to accept a comma-separated list of ports so that if a client has a preference for ports they can be tried in-order. We could do this in the client, but it feels a bit clumsy to keep trying to spawn processes repeatedly until it works, so I thought this would be cleaner (though if you think it's weird putting this here, we could do that).This is working towards supporting DevTools on CrOS without Linux Chrome. It will still rely on the VM service being also being available on an exposed port (I haven't dug into that yet).
Example output below. First we bind something to port 8000:
If we attempt to bind to it again:
Machine output looks like this:
If we provide additional ports, it will try them in-order:
And machine output:
Finally, if you want - you can include
0in the list to accept any port (as before):I did consider including a flag that tries the CrOS-exposed ports to avoid clients having to deal with it, but it seemed a little specific. LMK if you'd prefer that though. We could even change the default from
9100to8000, 8008, 808, 8085, 8888, 9005, 3000, 4200, 5000, 9100but that also looks kinda specific. Note: as far as I can tell, there's no easy way to detect when running in a CrOS Linux container besideshostname == 'penguin'which may not be reliable.Also something I haven't done, but we could - is make the default normally
9100,0. This would avoid failures if the port was already bound while still having a preference for 9100 to avoid the randomness if you want to bookmark/whatever.