Hi there, thanks for this information.
Is there any plan to add support for multiple manifest.json files to Connect in the future?
My organization used to install our internal packages manually to try this out but found it a bit cumbersome (we would have to log into our production server, build the R package, and then place it in the appropriate location on the server - at which point push-button deployments are easier to manage).
We now use RSPM and structure all of our deployed content (shiny apps, rmd scripts, plumber APIs) as R packages but still have some awkwardness with git-backed deployments, example;
- We develop an R package that includes a shiny app (using {golem}) and a Plumber API in one git repo on Github.
- This package is synched with RSPM so when a new version is tagged on Github RSPM will fetch the new version sometime soon (according to RSPM's poll frequency).
- This Shiny app and Plumber APIs are also set up with git-backed deployment to auto-deploy to Connect sometime soon after changes are merged into the
main branch (according to Connect's poll frequency).
Issue: If I merge some code changes into main, and tag the release, depending on the timing of Connect's and RSPM's polling, Connect may try to deploy the plumber and shiny apps before the new version of the package is available on RSPM.
A solution to this would be to have 2 Github repos; one for the R package and another for the deployments but this requires additional management and manual effort - to reflect any code changes in our deployed applications we need to push updates to 2 repositories (again at which point push-button deployment is potentially easier to manage).
Appreciate any thoughts here or if you have any other suggestions for how to structure projects that share code but have multiple deployment targets - thanks in advance!