hadley
commented
1 year ago e.g. shim out install.packages(), devtools::install_*, remotes::install_*
Add shim to Sys.getenv() that reports when an environment variable is used.
Open hadley opened 1 year ago
hadley
commented
1 year ago e.g. shim out install.packages(), devtools::install_*, remotes::install_*
Add shim to Sys.getenv() that reports when an environment variable is used.
jthomasmock
commented
1 year ago It would be nice to start dry_run() in terms of the deployment will absolutely fail:
But also report on warnings:
Also wanted to note:
Posit Connect will scan your logs for common errors and suggest troubleshooting steps if an error is found. If you have encountered an error that Posit Connect is not detecting or for which Posit Connect is not providing adequate troubleshooting steps, you may wish to contact your administrator or your Posit Support representative.
While there ARE API endpoints for many of the above item, a failed deploy that actually goes through to Connect obviously reports on a lot more. Perhaps it's in scope to summarize the success/failures of the long set of logs?
hadley
commented
1 year ago FWIW the goal is to start with (IMO) the most common problems: missing dependencies and missing env vars.
csgillespie
commented
1 year ago Hi @hadley . We're (Jumping Rivers) are working on something similar just now. With a bit of luck, we'll make it public / open source in the next week or so. Basically, you stick in your API key / server name, and it runs through a bunch of tests. Here's the current output:
This seems to overlap with this issue? However, "our" package is trying to ensure that Connect is working as expected
We also have something similar for RSW
hadley
commented
1 year ago @csgillespie thanks, sounds like that's more about checking your connect instance is ok, not your content?
andpatt
commented
1 year ago sounds like that's more about checking your connect instance is ok, not your content?
For the majority aye, but I think there's a few bits that could crossover here.
There's a few bits that need access to the Connect API to check, but even if you didn't want to get bogged down in that, the following would still be doable:
Checking if the Connect URL looks valid - has a protocol and a trailing '/'
Checking if Connect's accessible - does it respond to a GET?
Checking whether each of the package sources in the manifest "look downloadable" - i.e. whether they're formatted correctly and you get a sensible response code from each. It's likely that your renv::restore() already checks this by just installing everything from the manifest though.
If you were also willing to interact with the Connect API (Since you're going to need to do the deploy anyway) then I think the following features implemented in the package referenced above would also be useful:
Does the user have permission to deploy an app to this connect server? (Check the user details for current user and check role is publisher or administrator.
Is the R version in the manifest one of those that the server has available? (server settings R) (you could do the same for Python and quarto content too).
If you wanted to get really involved in making sure that your content would deploy, then you could deploy a tiny plumber API which reads out the output of apt list --installed and cross reference that list against the system libraries needed by the packages your app uses.
But I suspect that's going a bit far for this function 😁
hadley
commented
1 year ago The first two are now more aggressively handled in addServer(), and since we now support redirects, I think the potential for problems after the fact are much slower. We have also have more checks for packages that are unlikely to work on the server, and you're right that restore() should capture the remaining cases.
The others seem ok to leave as server side errors to me as it's not like you can easily resolve the problem of mismatching R versions (which won't often cause problems?) or not having deploy access. Are these problems that you see a lot with users?
andpatt
commented
1 year ago The first two are now more aggressively handled in
addServer()
Ah yeah okay true.
The others seem ok to leave as server side errors to me as it's not like you can easily resolve the problem of mismatching R versions (which won't often cause problems?) or not having deploy access.
Yep, don't disagree with that
Are these problems that you see a lot with users?
Yeah they are, but we're generally seeing them when we've first deployed an environment and people are trying to use it with old versions of R they never told us about, or they all used to have a shared admin account to the old Connect and now they all login individually (and some viewers used to be admins, etc)
The R versions thing still occasionally bites users every time we update connect instances (because we remove the oldest minor version when we add a new minor version (with the client's consent!)) but again it's occasional because, as you say, things don't tend to break when using later R versions.
hadley
commented
1 year ago @andpatt hmmmm, maybe a sitrep() method would be a useful addition to rsconnect? That could give you that basic info for different servers.
Make it easier to diagnose issues locally by running the app in an environment that simulates what you'll get on the server.