Skip to content

Add ability to customize health check port

What does this MR do?

Making possible to override default behaviour of guessing healthcheck port (minimum port exposed by container if any). Instead of relying on exposed ports it takes the variable WAIT_FOR_SERVICE_TCP_PORT from target container (line 1267) if it's not empty. If it's empty, it keeps an old behaviour of guessing the port.

Why was this MR needed?

Problem is well described in #3984 (closed). I have noticed the issue was created three years ago, the general idea to make it all better is nice, but seems taking huge time and is a big change.

We use service which exposes dozens of ports, but not all of them are available. And not the minimum in the sorted order. We know for advance which port could be used for TCP probe.

What's the best way to test this MR?

Run any pipeline with service exposing ports 11001 and 11002 where 11001 is not available, but 11002 is. Try to set WAIT_FOR_SERVICE_TCP_PORT to each of them and leave empty. Health check should work correctly if WAIT_FOR_SERVICE_TCP_PORT=11002 only.

What are the relevant issue numbers?

#3984 (closed)

P.S. Sorry, I am not confident with Go language, my code may not compile correctly, I am not sure what is the syntax for getting variable from environment and checking if it's not empty. If line 1267 is wrong, it could be easy fix for experience Go developer (or I can fix it later when I find some time to read tutorial :-) ). I am more proposing idea than final solution.

Merge request reports