self-hosted
self-hosted copied to clipboard
getsentry
CI flakes with "Renaming a container with the same name as its current name"
Reticketing from https://github.com/getsentry/self-hosted/pull/1290#issuecomment-1028902426. Log link
Happens at:
https://github.com/getsentry/self-hosted/blob/da8f4903e4cfe47ca4fa5bf68265b62f795c60a0/_integration-test/run.sh#L45
Possibly https://github.com/docker/compose/issues/6704? But why? And how to avoid? 🤔
https://github.com/getsentry/self-hosted/runs/5100619223?check_suite_focus=true#step:4:2609
https://github.com/getsentry/self-hosted/runs/5162851843?check_suite_focus=true
https://github.com/getsentry/self-hosted/runs/5517601020?check_suite_focus=true#step:4:2698
https://github.com/getsentry/self-hosted/runs/5522537135?check_suite_focus=true#step:4:2360
https://github.com/getsentry/self-hosted/runs/5540753414?check_suite_focus=true#step:4:2367
From https://github.com/getsentry/self-hosted/pull/1365#issuecomment-1067074853 ...
multiple versions in same docker instance
@glensc Do you understand what's going on here and how to fix it?
From #1365 (comment) ...
multiple versions in same docker instance
@glensc Do you understand what's going on here and how to fix it?
Currently there is:
COMPOSE_PROJECT_NAME: self-hosted-${{ strategy.job-index }}
perhaps the job-index is always "0" (the value is not shown unless there's an error), maybe use ${{ matrix.compose_version }} instead? or new key specifically for this purpose.
@BYK Confirming ... did you intend to fix this ticket by setting COMPOSE_PROJECT_NAME in CI?
@BYK Confirming ... did you intend to fix this ticket by setting COMPOSE_PROJECT_NAME in CI?
No I did not. I intended to fix another one with "container has the same name" or something like that and that one seems to be fixed.
Possibly https://github.com/docker/compose/issues/6704? But why? And how to avoid? 🤔
@chadwhitacre adding --no-recreate to that command should fix it. Also adding --wait may make the waiting for Sentry to be up step redundant.
https://github.com/getsentry/self-hosted/runs/5620519447?check_suite_focus=true#step:4:2170
https://github.com/getsentry/self-hosted/runs/6953387418?check_suite_focus=true#step:4:3973
https://github.com/getsentry/self-hosted/runs/7158445726?check_suite_focus=true#step:4:3806
This has been fixed since docker-compose 2.2.4, what do you think about changing docker-compose versions in our CI to something greater than 2.2.4 and using --no-recreate ?
As this does not only affect CI, it will break users using docker-compose < 2.2.4 .
I don't think we can set docker-compose minimum version to 2.2.4 for users, but we can check for docker-compose version less than 2.2.4 and do not use --no-recreate though, and use no-recreate for docker-compose >= 2.2.4 .
Otherwise we keep getting hit this issue from time to time and won't be fixed.
2 days ago: https://github.com/getsentry/self-hosted/runs/7260082046?check_suite_focus=true#step:4:4126
what do you think about changing docker-compose versions in our CI to something greater than 2.2.4 and using --no-recreate
That would be great! Flaky CI is always rather annoying :/
I don't think we can set docker-compose minimum version to 2.2.4 for users, but we can check for docker-compose version less than 2.2.4 and do not use --no-recreate though, and use no-recreate for docker-compose >= 2.2.4 .
I think this seems reasonable, we might even want to give a warning about the potential issue?
Yeah, I think we can print something for users using >= 2.2.4 which we're changing their workflow that --no-recreate is getting added to their command and if they face a problem, report in this issue?
I will come up with a PR in the next days for this.
Reminder to my future self: Add/Replace a >=2.2.4 version of docker-compose to CI .
https://github.com/getsentry/self-hosted/runs/7869502187?check_suite_focus=true#step:4:1205
Seems we're not seeing this anymore closing, we can reopen if it occurs again.
lolsob
https://github.com/getsentry/self-hosted/actions/runs/4458020103/jobs/7829470226#step:4:11754