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
Running the migrations twice for each release may lead to race conditions and isn't the smart thing to do.
I'm currently amending the chart so we can disable running the dbmigrate job as a workaround. IMO running dbmigrate as it's own kubernetes Job is much cleaner than doing it as part of cmd.sh so i'd like to not keep the job enabled. I'm proposing we get rid of the command from cmd.sh and updating the docs to show how to run it locally with compose exec instead of having it run when you spin up the dev env. It's also likely that the current Job needs some tuning to ensure it runs at the right time during the sync process, this is something we'll want to tune once it's migrated to DBaaS.
The text was updated successfully, but these errors were encountered:
Currently migrations are both in the helm chart's
timed/templates/job-dbmigrate.yaml
as well as in the entrypoint:https://github.com/adfinis/timed-backend/blob/055dc6e4439bde4c164ca795c5e4624d57783f2c/cmd.sh#L8
Running the migrations twice for each release may lead to race conditions and isn't the smart thing to do.
I'm currently amending the chart so we can disable running the dbmigrate job as a workaround. IMO running dbmigrate as it's own kubernetes Job is much cleaner than doing it as part of
cmd.sh
so i'd like to not keep the job enabled. I'm proposing we get rid of the command fromcmd.sh
and updating the docs to show how to run it locally withcompose exec
instead of having it run when you spin up the dev env. It's also likely that the current Job needs some tuning to ensure it runs at the right time during the sync process, this is something we'll want to tune once it's migrated to DBaaS.The text was updated successfully, but these errors were encountered: