Adds a docker-compose setup to the repo, together with all formatting and linting tools used in the backend as well as automatic scripts and checks for them. Some notes:
I moved everything dev-related into a dev folder. For this to make sense (as everything in this repo is dev-specific, if you look at it that way), I interpreted the actual usage of the repo (holding the meta *.yml files) as its "productive" purpose. Then, everything related to testing/maintaining these files is "dev" stuff. This leads to a nice separation of intents and a cleaner overall structure, IMO.
There is no simple way to use multiple setup.cfg (or other config files) in one call to some python tool (e.g. isort). Therefore, I resorted to copying the config from the backend. If they were to diverge, this could lead to some annoying behaviour were the meta repo wants the files to be formatted in some way and the backend in the other. I deemed this risk to be pretty low as we do not change the setup.cfg often, but it's still something to keep in mind if it ever comes up.
I also copied the dependencies from the backend. This is somewhat redundant, as it would be easier to just include the requirements file from this repo in the backends requirements file. I decided against this, however, as the requirements are automatically kept up-to-date via dependabot, which means the backend and the meta repo will get updated simultaniously. If we incuded the requirements file from here in the backend, the backend would get no automatic updates, which might lead to some problems when one wants to update the meta repo's hash in the backend for some unrelated feature. This could be solved via another GitHub action which automatically updates the meta repo in the backend after some dependency changed, but for now I decided against this.
@r-peschke With this setup, it should be easily possible to add a /dev/tests folder which includes all tests and can be executed via pytest. As the setup is never used for anything else, I think we can just hardcode the postgres access data (host, port, user, db, password) in the test code and don't need to make it configurable via some env vars.
Adds a docker-compose setup to the repo, together with all formatting and linting tools used in the backend as well as automatic scripts and checks for them. Some notes:
devfolder. For this to make sense (as everything in this repo is dev-specific, if you look at it that way), I interpreted the actual usage of the repo (holding the meta*.ymlfiles) as its "productive" purpose. Then, everything related to testing/maintaining these files is "dev" stuff. This leads to a nice separation of intents and a cleaner overall structure, IMO.setup.cfg(or other config files) in one call to some python tool (e.g. isort). Therefore, I resorted to copying the config from the backend. If they were to diverge, this could lead to some annoying behaviour were the meta repo wants the files to be formatted in some way and the backend in the other. I deemed this risk to be pretty low as we do not change thesetup.cfgoften, but it's still something to keep in mind if it ever comes up.@r-peschke With this setup, it should be easily possible to add a
/dev/testsfolder which includes all tests and can be executed viapytest. As the setup is never used for anything else, I think we can just hardcode the postgres access data (host, port, user, db, password) in the test code and don't need to make it configurable via some env vars.