Update API database using OpenPedCan-analysis v12 final release data

[logstar]

Updated API database using OpenPedCan-analysis v12 final release data. The following filtered files in s3://d3b-openaccess-us-east-1-prd-pbta/open-targets/v12/api-data/ were used for building the API database:

• efo-mondo-map.tsv
• ensg-hugo-pmtl-mapping.tsv
• gene-counts-rsem-expected_count-collapsed-deseq.rds

The filtered files were generated by the filter-mtp-tables module in the OpenPedCan-analysis.

Resolved #86

Type of change

Changed

• Updated database using OpenPedCan-analysis v12 final release data.
• Changed db/build_db.sh to download OpenPedCan-analysis api-data using db/build_tools/download_api_data.sh.
• Changed db/build_tools/build_db_docker_cmd.sh to compress intermediate CSV files.

Added

• Added db/build_tools/download_api_data.sh to download OpenPedCan-analysis api-data.

How Has This Been Tested?

Terminal returns for testing DEV host:

$ API_HOST=dev ./tests/run_tests.sh
API base URL: https://openpedcan-api-dev.d3b.io
✔ |  OK F W S | Context
✔ | 885       | tests/r_test_scripts/test_endpoint_http.R [3952.2 s]

══ Results ════════════════════════════════════════════
Duration: 3952.2 s

[ FAIL 0 | WARN 0 | SKIP 0 | PASS 885 ]
Done running run_tests.sh

For more details about testing environment, options, and resources, see README.md.

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [NA] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules
• [x] I have checked my code and corrected any misspellings
• [ ] I have emojis in my PR and commits 😉

[logstar]

Hi @kelseykeith . Thank you for reviewing the PR.

I was wondering if the lsb-release issue could be addressed in a separate issue/PR. The current v12 final-release database was built on an ubuntu EC2 instance without installing lsb-release in the db/build_tools/build_db.Dockerfile. The lsb-release error might need to be reproduced with major changes to the local v12 final-release database building environment, such as docker version, docker image version, and operating system version. The local building environment changes might cause additional dependency issues. Therefore, I was wondering if it might be more efficient to resolve the lsb-release issue in a standalone PR, or a PR that starts development with the lsb-release installed.

[kelseykeith]

Yes, I'm fine with that. I can either submit a standalone PR for the issue or include it with my CNV database PR once we get there

[logstar]

Thank you. I will also add lsb-release installation to the db/build_tools/build_db.Dockerfile before working on the next issue.

I will merge this PR soon to update the QA API site.