connectapi
connectapi copied to clipboard
Update from git but don't trigger run?
👋 thanks again for this awesome package.
I currently have a scenario where I have a run of a git-backed rmd being triggered externally via {connectapi}. This basically happens on a nightly basis. I'd love to have the ability to before doing that run, if i could trigger a check to make sure the rmd on connect is up to date with the latest commit and if not update the connect rmd with the latest changes. deploy_repo_update does this but it also triggers a run. Would you be open to a PR that a) add documentation that clarifies that deploy_repo_update does this and b) adds an argument that defaults to the current behaviour but can be changes to just update and re-run?
Here is sort of a reprex:
library(connectapi)
library(curl)
library(glue)
client <- connect(
server = secrets,
api_key = secrets
)
report <- content_item(client, rmd_id)
## trigger update from git repo if needed
deploy_repo_update(report)
## get the id for the default variant
rmd_content_variant <- get_variant_default(report)
## render the rmd
rendering <- variant_render(rmd_content_variant)
Howdy @boshek! This is a fantastic use case! Thanks for reaching out here and articulating so clearly. We definitely would welcome such a PR - this is a problem that we have actually had requested several times outside of the context of git.
Thankfully, it looks like git gives us a bit of flexibility here. (But we still have a bit of work to do on the "deploy / update without re-running" story overall in the product - there is currently no way to decouple "deploy" from "run").
The way I envision this working:
- refactor
deploy_repo_update()to have a separatedeploy_repo_check()function that checks whether there are updates or not (returns a boolean)- Basically I suspect it would be nearly everything except this deploy at the end https://github.com/rstudio/connectapi/blob/0987e44423afe70a99bf360e94fd1cfa97c79850/R/git.R#L149
- switch
deploy_repo_update()to usedeploy_repo_check()internally - you would use
deploy_repo_check()to decide whether to "update to latest" or run your report. Pseudocode:
if (deploy_repo_check(report)) {
deploy_current(report)
# will run the default variant as a part of the deploy process
} else {
## get the id for the default variant
rmd_content_variant <- get_variant_default(report)
## render the rmd
rendering <- variant_render(rmd_content_variant)
}
One downside of this approach is that it only works for the default variant IIRC (i.e. other variants may not be triggered by the deploy process?). I must admit I forget the specifics though. Documentation improvements here are always most welcome! In particular, it will be good to check what the state is if you check twice or more but do not deploy.
We have a CI system that can run checks on this sort of thing to protect the behavior, however I will admit that this type of integration test is a bit tricky to set up. If you want to take a pass at implementing this, I am happy to write the test coverage, or you are welcome to give that a shot too! (I suspect this one will be particularly yucky / may need some mocking since otherwise a git repo will need to change mid-test 😱 ).
Does that seem to align with your expectations for how it might work? Are you interested in taking a pass at this? 😄
One quick aside, this function has a couple of error cases. Is this the behavior that you would expect from the client library: failure in cases where the git operations are now invalid?
https://github.com/rstudio/connectapi/blob/0987e44423afe70a99bf360e94fd1cfa97c79850/R/git.R#L137-L144
EDIT: Updated to point to deploy_current() instead of report$deploy()