Speed up environment teardown by removing docker stop command
What does this MR do and why?
Some low hanging fruit to shave up to 10 seconds per running container in the test teardown phase. On most pipelines this will most likely just be a single container, but on others such as the praefect jobs, we can have 5 gitlab-ee
containers running so the issue is amplified further there.
Description:
Using docker stop
sends a SIGTERM to the process, which has a default timeout of 10secs (see docker stop --help
).
If the process doesn't stop within this period, it sends a SIGKILL to terminate the process, so you'll often see that docker stop
takes 10 seconds to complete.
eg a recent master build https://gitlab.com/gitlab-org/gitlab-qa-mirror/-/jobs/2392480617#L4351 -- note the 10s lag between the commands.
[date=2022-04-28 21:29:06 from=Gitlab QA] INFO -- Docker shell command: `docker stop gitlab-gitaly-cluster`
[date=2022-04-28 21:29:16 from=Gitlab QA] INFO -- Docker shell command: `docker rm -f gitlab-gitaly-cluster`
When testing docker stop --time 60
against our gitlab/gitlab-ee
containers, it appears to actually take 10s-15s to gracefully stop the containers so we aren't actually giving enough time to gracefully stop today as it is.
I don't think we have any reason here to worry about gracefully stopping the container, considering the very next step is to run docker rm -f
so we can save a little time here across every orchestrated test by bypassing the stop
command and just using rm -f
directly.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.