You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might already work with start-server-and-test apparently because of the ability of the wait-on package to wait for an open tcp port instead of for a http response.
There are quite many tools that offer some kind of port forwarding (for example kubectl, ssh, google cloudsql proxy, aws system manager) and it is common to have to wait for e.g. a database to be available in tests or to execute database migration scripts against it in deploy job.
The current name of the package start-server-and-test does not seem well suited to this more general use case, but the functionality is the needed one. To support this use case, one would have to
Expand the README.md a bit with an added example of this use case
Change some console.log to console.error to not contaminate the stdout stream of the executed command to allow piping it into other tools.
What do you think?
The text was updated successfully, but these errors were encountered:
Currently, the intended scope of the package is only to wait for http servers for tests.
It is not anticipated to forward a port to a remote host to execute a command against it.
For example, a postgres database may not expose its port directly to the internet, but one can use ssh to forward the port onto localhost.
This might already work with
start-server-and-test
apparently because of the ability of thewait-on
package to wait for an open tcp port instead of for a http response.There are quite many tools that offer some kind of port forwarding (for example kubectl, ssh, google cloudsql proxy, aws system manager) and it is common to have to wait for e.g. a database to be available in tests or to execute database migration scripts against it in deploy job.
The current name of the package
start-server-and-test
does not seem well suited to this more general use case, but the functionality is the needed one. To support this use case, one would have toconsole.log
toconsole.error
to not contaminate the stdout stream of the executed command to allow piping it into other tools.What do you think?
The text was updated successfully, but these errors were encountered: