Unify how we run tests and the code locally

syphax-bouazzouni commented 1 year ago

Currently to run tests , there is all this (historical) options:

run-unit-tests.sh
docker_infrastructure.rb
run_tests.rb
Run the docker compose with port forwarding then bundle exec rake test (what I do)
A github action that use docker-compose.yml

I think we need to harmonize how we run tests, by (if possible):

[ ] Make run_tests.rb use the docker-compose.yml file
[ ] Remove run-unit-tests.sh and docker_infrastructure.rb if no more used
[ ] Make the CI test action use run_tests.rb (optional, but its better to use everywhere the same script)
[ ] Add documentation of how to run the tests using run_tests.rb

That was for testing, but why can't we use the same docker-compose.yml for development ?

[ ] Adding a script to build an environment using the same docker-compose but with port forwarding

syphax-bouazzouni commented 1 year ago

@alexskr what do you think about this?

FYI @ontoportal/industryportal , @ontoportal/ecoportal, @ontoportal/bioportal

alexskr commented 1 year ago

I agree it would be a good idea to update and standardize the way we run unit tests.

Our current approach is to run bundle exec rake test inside a container (ruby) that connects to backend services running on other containers. This way developers do not need to worry about installing dependencies in their personal mac/pc/linux environments and simply rely on pre-configured containers. Unit tests run in a linux environment which is close to how we run stuff in production. More than once we run into platform-specific issues which made unit tests work differently on mac vs linux. It is also possible to simultaneously run tests from different projects without running into port conflicts.

Most of BioPortal developers use RubyMine which has a way to interact with containers but I do not think that we have fully switched development to use docker-based workflows yet.

One thing that can make it easier to use docker-based workflows is dip which stands for Docker Interaction Program. For example, to run unit tests I simply run dip test on my console which spins all necessary containers and runs unit tests. To install or update gems I run dip bundle update and dip spin up just the ruby container to install gems.

run-unit-tests.sh is a script to demonstrate how to run unit tests with docker but it is somewhat redundant if users adopt using dip for it.
docker_infrastructure.rb can be archived/removed. The only reason why I haven't done so yet is that at some point in the past docker_tests_forked intrigued me and I was going to see if it can run multiple unit jobs at the same time but I haven't gotten to it.
run_tests.rb is no longer needed and could be removed once we confirm that Misha no longer relies on it.

syphax-bouazzouni commented 1 year ago

Yeah, dip seams great to hominize our workflows. Can you (@alexskr) share with us your configuration files (your dip.yml on a pull request).

I think we will need at least those dip interactions:

dip serve (run development server for the API project (docker compose up + bundle exec shutgun))
dip test (run current project tests)
dip update (run bundle update)

syphax-bouazzouni commented 1 year ago

Yeah, dip seams great to hominize our workflows. Can you (@alexskr) share with us your configuration files (your dip.yml on a pull request).

I think we will need at least those dip interactions:

dip serve (run development server for the API project (docker compose up + bundle exec shutgun))

dip test (run current project tests)

dip update (run bundle update)

Ah sorry there was already shared 4 month ago, I didn't seen it. (still need a documentation and dip serve) https://github.com/ontoportal/ontologies_linked_data/blob/master/dip.yml

ontoportal / ontologies_linked_data

Unify how we run tests and the code locally #1