Simplifies the service project resulting from this cookiecutter by delegating tooling and standard testing to osparc-simcore's service library or ooil in short.
We have moved most of the code in the cookiecutter to ooil library (which lives in osparc-simcore repo). The idea is that there is now a single source of truth : basically the metadata.yml and docker-compose-build.yml files. Then ooil can deduce everything from it.
Next iteration will introduce the .osparc folder approach (but one step at time :-) )
This leads to a much simpler layout! Just FYI, the resulting service project, compared to the previous version :
removes tools folder code
removes versioning folder
removes VERSION files (can be regenerated with ooil
replaces test code by assert_* helper functions ( test skeleton is maintained in this iteration but could be further simplified)
moved gitlab/github specific routines in ci to .gitlab and .github folders resp
improved Makefile recipes ( w/o breaking the interface in this iteration)
How to test
Could you please try this with one of your services? To create a service project using this cookiecutter + python 3.9 just
$ ls -la
$ make devenv
$ source .venv/bin/activate
$ ooil --version
$ make build
$ make tests
# then can try other recipes
$ make help
$ make VERSION
$ make replay
Related issue number
ITISFoundation/osparc-issues#694 : proactive onboarding of models and services (Y6)
ITISFoundation/osparc-issues#304: (Part 2) Prep2Go: creating features to support complex S4L scripts
ITISFoundation/osparc-issues#693: creation of own oSPARC services
Checklist
[x] change version
[x] add reference to master
[x] fix failing tests: issue with source-ing in a subprocess! (@sanderegg any idea on test_bake_project.py issue?)
[x] Unit tests for the changes exist
[x] Documentation reflects the changes
[x] If you design a new module, add your user to .github/CODEOWNERS
What do these changes do?
Simplifies the service project resulting from this cookiecutter by delegating tooling and standard testing to osparc-simcore's service library or
ooilin short.We have moved most of the code in the cookiecutter to
ooillibrary (which lives in osparc-simcore repo). The idea is that there is now a single source of truth : basically themetadata.ymlanddocker-compose-build.ymlfiles. Thenooilcan deduce everything from it.Next iteration will introduce the
.osparcfolder approach (but one step at time :-) )This leads to a much simpler layout! Just FYI, the resulting service project, compared to the previous version :
toolsfolder codeversioningfolderVERSIONfiles (can be regenerated withooilassert_*helper functions (testskeleton is maintained in this iteration but could be further simplified)cito.gitlaband.githubfolders respHow to test
Could you please try this with one of your services? To create a service project using this
cookiecutter + python 3.9justThen
cdthe "baked" project andRelated issue number
Checklist
source-ing in asubprocess! (@sanderegg any idea ontest_bake_project.pyissue?)