Related to #44
Redoing the entire PR because I didn't like that #46 was based on my forked master branch
Setting up GitHub Actions on the repo, only current action is to run tests (pytest) on frontend component
What was done
test GitHub Action which contains all the testing configurations to be run on merges to master
adding a specific Dockerfile for the test environment (less dependencies than prod image for now), see associated test-.requirements.txt
adding a specific docker-compose file for the frontend tests (single service for now)
does 2 kinds of requirements.txt make sense? It does help cut down the build time on the GitHub Action workflows and better keeps track of what we are testing, although there might be duplication. This is when things like Pipenv would shine as you can have 'dev' dependencies separate from prod dependencies on a single file.
What is next?
Add valid tests and refine the workflow if need be
create another workflow (or keep the same one but add parallel steps) for the backend component
Summary
Related to #44 Redoing the entire PR because I didn't like that #46 was based on my forked
masterbranch Setting up GitHub Actions on the repo, only current action is to run tests (pytest) on frontend componentWhat was done
masterDockerfilefor the test environment (less dependencies than prod image for now), see associatedtest-.requirements.txtdocker-composefile for the frontend tests (single service for now)Questions/concerns
requirements.txtmake sense? It does help cut down the build time on the GitHub Action workflows and better keeps track of what we are testing, although there might be duplication. This is when things likePipenvwould shine as you can have 'dev' dependencies separate from prod dependencies on a single file.What is next?