-
Notifications
You must be signed in to change notification settings - Fork 365
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
Use docker-compose to run tests #1221
Conversation
Move the testing logic from the Github Actions format to a more easy to reproduce docker-compose file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know docker, so I'll let you test that it works - it seems you're also still tweaking codecov. For the moment I left a comment for you, the rest looks fine for as much I know.
Codecov Report
@@ Coverage Diff @@
## master #1221 +/- ##
==========================================
- Coverage 63.51% 63.44% -0.07%
==========================================
Files 233 233
Lines 17151 17151
==========================================
- Hits 10893 10882 -11
- Misses 6258 6269 +11
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! Please look at those two nits and squash the commits as necessary for them to make sense before pushing!
Move the testing logic from the Github Actions format to a
docker-compose.test.yml
file. The advantage of this approach is that we can now run tests locally in a easy and reproducible way.Moreover, instead of using
sed
at runtime to inject the test database string intocms.conf
, we now always add acms-testdb.conf
file next tocms.conf
in the/usr/local/etc/
folder as part of the build step of the docker container. We then decide which config file to use based on the already-supportedCMS_CONFIG
environment variable. (I had to patchtestrunner.py
which was not supporting that variable yet.)One possible next step in this direction could be using this approach also for local development, with a
cms-devdb.conf
file which likewise always gets copied in the etc folder, and adocker-compose.dev.yml
which uses it to start the DB and the local CMS instance. It's also possible to re-use theDockerfile
in production, but I wouldn't try to support that use case seriously just yet (I think the contest admins can write adocker-compose.yml
fitting their specific needs).