rstudio / rsconnect

Publish Shiny Applications, RMarkdown Documents, Jupyter Notebooks, Plumber APIs, and more
http://rstudio.github.io/rsconnect/
131 stars 80 forks source link

Push button deploys that fail on first deploy create a bundle that can't be accessed again by push button #778

Closed jthomasmock closed 1 year ago

jthomasmock commented 1 year ago

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

  1. Create a RMarkdown or Quarto doc:
---
title: "test"
format: html
---

```{r}
library(ggplot2)

ggplot(mtcars, aes(x = disp, y = mpg)) +
  geom_point()
if(Sys.getenv("test_var") == "test"){
  return("Wahoo")
} else {
  stop("Missing env var!")
}


2. Push-button deploy to Connect
3. Receive failure in console
4. Go to failed deploy on Connect, add env var - get a successful deploy
5. Try to re-deploy the same content, and it starts the workflow at step 2 😢 

## Actual Behavior

Failed deploy and inability to "save" that connection to the failed bundle on Connect.

## Expected Behavior

Failed deploy, maintain connection via Push-button, can modify the env-var on Connect, and then re-deploy with any subsequent updates to the same bundle guid.
aronatkins commented 1 year ago

Removed internal links / names.

aronatkins commented 1 year ago

@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?

hadley commented 1 year ago

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.

jthomasmock commented 1 year ago

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.

hadley commented 1 year ago

Since this is tracked in the IDE, I'm going to close this one.