-
Notifications
You must be signed in to change notification settings - Fork 260
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.
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
Implement proper health-check for databases #160
Comments
stronk7
added a commit
to stronk7/moodle-docker
that referenced
this issue
May 17, 2021
Basically does the same than old Travis runs, with some differences: - I've grouped the jobs into 3 categories (phpunit, behat, app). - Each one has own setup/teardown/test shell script, instead of the previous "mammoth" setup and test scripts, that I've left unmodified - Aiming to get the travis CI runs disabled because they are super slow (we only have 2 concurrent jobs allowed) and, while running, all the other moodlehq repos have to wait. - I'll create an issue to remove travis support once this is accepted and working ok. - Only change that I had to perform to existing stuff is raising the hardcoded sleep of 5 seconds to 10 seconds because I was getting some random failures with MySQL, needing more time to start. - We should move to proper health-checks for database (moodlehq#160) containers soon, much like app containers (moodlehq#131).
stronk7
added a commit
to stronk7/moodle-docker
that referenced
this issue
May 17, 2021
Basically does the same than old Travis runs, with some differences: - I've grouped the jobs into 3 categories (phpunit, behat, app). - Each one has own setup/teardown/test shell script, instead of the previous "mammoth" setup and test scripts, that I've left unmodified - Aiming to get the travis CI runs disabled because they are super slow (we only have 2 concurrent jobs allowed) and, while running, all the other moodlehq repos have to wait. - I'll create an issue to remove travis support once this is accepted and working ok. - Only change that I had to perform to existing stuff is raising the hardcoded sleep of 5 seconds to 10 seconds because I was getting some random failures with MySQL, needing more time to start. - We should move to proper health-checks for database (moodlehq#160) containers soon, much like app containers (moodlehq#131).
stronk7
added a commit
to stronk7/moodle-docker
that referenced
this issue
May 17, 2021
Basically does the same than old Travis runs, with some differences: - I've grouped the jobs into 3 categories (phpunit, behat, app). - Each one has own setup/teardown/test shell script, instead of the previous "mammoth" setup and test scripts, that I've left unmodified - Aiming to get the travis CI runs disabled because they are super slow (we only have 2 concurrent jobs allowed) and, while running, all the other moodlehq repos have to wait. - I'll create an issue to remove travis support once this is accepted and working ok. - Only change that I had to perform to existing stuff is raising the hardcoded sleep of 5 seconds to 10 seconds because I was getting some random failures with MySQL, needing more time to start. - We should move to proper health-checks for database (moodlehq#160) containers soon, much like app containers (moodlehq#131).
stronk7
added a commit
to stronk7/moodle-docker
that referenced
this issue
Jul 25, 2022
We have ensured that all the oracle database images output at the end of the init script the "DATABASE IS READY TO USE!" text. That has been done by: moodlehq/moodle-db-oracle#13 (Because Oracle 11g was missing that string) So, now that the string is available in all moodle-db-oracle images we can start using it here, in moodle-docker. Still note this is not the ideal wait/health-check system and we'll have to move to a proper one. See: moodlehq#160 But it's better than nothing, and the current one based on the "Database opened." string was not working ok for Oracle 21c (that requires 2 startups).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Similar to #131 , but to ensure databases are available.
The text was updated successfully, but these errors were encountered: