Skip to content
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.

Sign up for GitHub

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

Jump to bottom

e2e tests should fail gracefully if the ports are not available (or find a new port) #9491

Open
jkuester opened this issue Oct 2, 2024 · 0 comments
Open

e2e tests should fail gracefully if the ports are not available (or find a new port) #9491

jkuester opened this issue Oct 2, 2024 · 0 comments
Labels
Type: Technical issue Improve something that users won't notice

Comments

@jkuester
Copy link
Contributor

jkuester commented Oct 2, 2024

Describe the issue

The e2e tests use docker compose to spin up the CHT containers to run the tests against. The nginx container tries to bind to the default ports 80/443 and the e2e tests running on the host machine will communicate with the containers via these ports.

However, if those ports are not available (e.g. something else like the https://github.com/medic/nginx-local-ip service is already bound to them) the nginx container will fail to start. The way this gets presented to the end user (when running npm run wdio-local) is very confusion, though (as noted in #9422). The tests start the containers in the background and then poll until the api server is available. But if the nginx container fails to start the e2e tests will just continue polling forever with the error:

Checking API
API check failed, trying again in 1 second
502 - "<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body>\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.19.10</center>\r\n</body>\r\n</html>\r\n"

Describe the improvement you'd like

One solution would be to simple end the e2e test run (with a helpful error message) if any of the docker containers fail to start.

Alternatively, I do not think there is any hard requirement that the e2e tests use 80/443. Instead it seems like we might be able to use custom ports that we determine at runtime are available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Technical issue Improve something that users won't notice
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jkuester