test(package): #41 Add infrastructure for manual testing

[AlexAxthelm]

Add a docker-compose file to spin up a testing database alongside the container for manual testing.

Also add some mock testing data in support of get_issue_code_bridge()

current testing steps:

docker-compose up

# in another terminal:
docker attach workflowfactset-workflow.factset-1 # enters the workflow.factset container

#in that container
library(workflow.factset)
conn <- connect_factset_db()
issue_code_bridge <- get_issue_code_bridge(conn = conn)
issue_code_bridge
# A tibble: 9 × 5
#   issue_type_code issue_type_desc   asset_class_code asset_class_desc asset_type
#   <chr>           <chr>             <chr>            <chr>            <chr>
# 1 00              N/A               NA               NA               Other
# 2 BB              Bond              W                NA               Corporate…
# 3 DD              Debenture         W                NA               Corporate…
# 4 EE              Equity            X                Bond             Listed Eq…
# 5 02              Dual Listing      X                Bond             Listed Eq…
# 6 F2              Closed-End Mutua… X                Bond             Fund
# 7 F1              Exchange Traded … X                Bond             Fund
# 8 LL              Loan              Z                Other            Other
# 9 NN              Note              Z                Other            Corporate…

Closes: #41

[github-actions[bot]]

Docker image from this PR (2cca7bd7bc542b75a2121b7517994ce26041ad66) created

docker pull ghcr.io/rmi-pacta/workflow.factset:pr42

[AlexAxthelm]

Note that this is a stopgap measure, for manual testing. I haven't found a good way to mock a PG database other than actually running one in a container, but that isn't going to play well with testthat, so that's a different conversation.

Creating the code in tests/sql was done by extracting snippets from the output of pg_dump -f foo.sql -F plain --schema-only

Future work:

• Support more tables
• Automate tests

[AlexAxthelm]

Another note here: this is only doing "happy-path" testing.

[cjyetman]

I get an error when running docker-compose up

2.348 Error:                                                                                                              
2.348 ! error in pak subprocess                                                                                           
2.348 Caused by error in `loadNamespace(x)`:                                                                              
2.348 ! there is no package called ‘pkgdepends’    

I suspect this is because of a combination of:

• running on an arm64 Mac
• using a Dockerfile that does not explicitly set a platform, in which case arm64 is chosen by default for me
• the CRAN repo is set to a Posit Package Manager URL
• Posit Package Manager seems to be having difficulty returning proper arm64 linux builds of packages, e.g. it returns something, but it's not an actual binary (source, but not compiled)

I modified the Dockerfile with FROM --platform=linux/amd64 rocker/r-ver:$R_VERS AS base and it successfully built the image.

After that, I get the error

Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /host_mnt/Users/cjrmi/github/pactaverse/workflow.factset/outputs

I suspect that means that ./outputs must exist, or that I must point this https://github.com/RMI-PACTA/workflow.factset/blob/455bb8441c55b1fbb27d9886eee81912060ef422/docker-compose.yml#L20 to an existing directory.

I created the directory ./outputs first and then re-ran docker-compose up and that appeared to function as expected.

Once that was running, I ran docker attach workflowfactset-workflow.factset-1 which drops me in a shell with prompt >. It was not clear to me that this was an R prompt, but I tried running the R code in it

library(workflow.factset)
conn <- connect_factset_db()
issue_code_bridge <- get_issue_code_bridge(conn = conn)
issue_code_bridge

and I appear to get the same result as above 🎉

1. I would strongly suggest documenting how to run this clearly in the README (or wherever appropriate)
2. I would suggest including instructions on how to properly turn these things off and clean up... I used quit() in the second shell and Ctl-C in the first, but not entirely sure it that is/was most appropriate or if anything else should be done.

[AlexAxthelm]

Thanks for the review @cjyetman. I've opened #43 to note the arm64 issues, and updated the readme with instructions.