rstudio / rsconnect

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

Collaborator source RMD publishing creates a new app instead of a new bundle #1007

Closed dbkegley closed 8 months ago

dbkegley commented 9 months ago

rsconnect: 1.1.0 Connect: 2023.10.0-dev+216-g70573d7869

  1. Add Admin and Publisher users as connections in the IDE
  2. Deploy an RMD (with source) as the Admin from the IDE
  3. Add the Publisher as a collaborator in the Connect dashboard
  4. In the IDE, remove the Admin user connection
  5. Re-deploy the same RMD (with source) as the Publisher from the IDE
Screenshot 2023-09-27 at 12 12 25 PM

actual: A new App is created (owned by the Publisher)

expected: A new bundle should be created for the existing App (owned by the Admin)

see also: ~https://docs.posit.co/tutorials/user/publishing-with-collaboration-on-rsc/~ (obsolete) see also: https://docs.posit.co/connect/user/publishing/#publishing-collaboration

dbkegley commented 9 months ago

We have also seen this bug in Version: 1.0.1 so it may have been introduced initially with the 1.0.0 refactoring

toph-allen commented 9 months ago

You can work around this issue by using the appID argument to rsconnect::deployApp(), e.g.

rsconnect::deployApp(appDir = ".", appId = "a2859a31-4326-4125-9deb-39f31e5d4fbc")
aronatkins commented 8 months ago

The v0.8.29 release falls into this clause when determining the deployment target: https://github.com/rstudio/rsconnect/blob/9ce427edf03b6d243a4074264dbc950242b0a295/R/deployApp.R#L681-L686

The IDE calls deployApp() using the content name from the previous deployment, but uses the account associated with the (local) collaborator account. I have not uncovered how the IDE determines which account to provide when calling deployApp(). https://github.com/rstudio/rstudio/blob/afbabb533c00add040c124126438177457ba5592/src/cpp/session/modules/SessionRSConnect.cpp#L280

aronatkins commented 8 months ago

When the IDE recognizes that the target deployment does not correspond with an account that is configured, it attempts to discover a local account on the same server. As a result, rsconnect::deployApp() can be called with the original content name and server but a different account.

https://github.com/rstudio/rstudio/blob/afbabb533c00add040c124126438177457ba5592/src/gwt/src/org/rstudio/studio/client/rsconnect/ui/RSConnectDeploy.java#L760-L796

rsconnect::deployApp() needs to use name and server, but ignore app, to correctly target these deploys.

hadley commented 8 months ago

Would it be useful to have a function that detects when deployApp() is being called by RStudio? Then we could make the IDE specific logic more clear.

aronatkins commented 8 months ago

Related: When targeting a deployment, there are two accounts:

  1. The original account that created the content.
  2. The current account attempting to update the content.

With 0.8.29, these concepts were (mostly) separate, though not obviously so. The distinction between these two accounts was lost with 1.0.0.

We will need deploymentTarget to indicate the updating account without modifying the deployment record.

aronatkins commented 8 months ago

Would it be useful to have a function that detects when deployApp() is being called by RStudio? Then we could make the IDE specific logic more clear.

I do not believe that we need to understand when we are being called by the IDE. I think the mistake was not understanding that the incoming account might not match the account on the deployment record. That expectation was very subtle in the 0.8.29 workflow. I'm actively trying to make that more explicit.

aronatkins commented 8 months ago

We believe that this problem is resolved in the development version of rsconnect.

remotes::install_github("rstudio/rsconnect")