Closed jthomasmock closed 1 year ago
Removed internal links / names.
@hadley - this has been improved by some of your work, yes? Is that far enough along (deployment records saved even on failure) for folks to test?
I think in principle it has helped, but there's a separate problem with the IDE: https://github.com/rstudio/rstudio/issues/12707. I think that's the root cause here.
I agree with your thoughts - the IDE logging the guid even on failure is important. That would allow a reattempt against the same bundle, even before the IDE "knew" that the deployed content is now valid on Connect's end.
Since this is tracked in the IDE, I'm going to close this one.
Origin of Bug
In a recent demo, a user mentioned that he ran into a frustration during publishing. He is running into the "fail on first push-button deploy issue when using an env variable". I know the team has already addressed some of that with deploying via
rsconnect
or git-backed publishing.The actual bug is that once that push-button deploy has failed, it creates a bundle/deployed item on Connect. A user could go into Connect and add the env-var and make the deployed content render successfully. However, the propagation of that now successful deploy guid BACK to the RStudio IDE is not automatic, so push-button deploying the exact same piece of content again with an update (say an additional code chunk) creates an additional bundle and the same original failure (missing env var) leading to some recursively frustrating behavior.
Potential workaround: In their local RStudio session, a user could find and manually modify the specific deployment's dcf file within the project's rsconnect folder.
Problem Statement
A failed push-button deploy that is successfully corrected on Connect is not propagated back to the local environment in RStudio or the push-button deploy interface. This leads to a recursive problem when trying to publish documents that rely on environmental variables, and potentially other failure conditions.
Steps to Reproduce