[ ] CLI does as little as possible, and especially doesn't write any data to the file system that other containers will need to read
Testing
No response
Documentation
No response
Dependencies
No response
Details and Comments
See #400 for why this causes a problem with file permissions, currently requiring an annoying workaround.
The CLI runs as a different user to the export API, but needs to write files that the latter can read.
If the CLI didn't do anything except tell the export API what to do, then it would be the export API doing all writing and reading, and it could hopefully also use a docker volume instead of the host file system, storage capacity allowing.
It should also give us a better design from a Separation of Concerns point of view. Ie. the UI shouldn't contain underlying program logic.
Potential problem: the exports API would need access to the OMOP ES extract directory, which would then itself need appropriate permissions setup (should be an easy one-off though?), and it may make it harder to point the export API to some other directory for testing purposes.
Workarounds for the latter:
Put the test omop extracts in a sibling directory to the live omop extracts, and mount the parent directory (readonly of course). Then specify all omop dirs relative to this root.
Just have a separate test extract directory which you mount in addition to the live one.
Definition of Done / Acceptance Criteria
Testing
No response
Documentation
No response
Dependencies
No response
Details and Comments
See #400 for why this causes a problem with file permissions, currently requiring an annoying workaround.
The CLI runs as a different user to the export API, but needs to write files that the latter can read.
If the CLI didn't do anything except tell the export API what to do, then it would be the export API doing all writing and reading, and it could hopefully also use a docker volume instead of the host file system, storage capacity allowing.
It should also give us a better design from a Separation of Concerns point of view. Ie. the UI shouldn't contain underlying program logic.
Potential problem: the exports API would need access to the OMOP ES extract directory, which would then itself need appropriate permissions setup (should be an easy one-off though?), and it may make it harder to point the export API to some other directory for testing purposes. Workarounds for the latter: