Closed dbkegley closed 8 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
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")
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
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.
rsconnect::deployApp()
needs to use name and server, but ignore app, to correctly target these deploys.
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.
Related: When targeting a deployment, there are two accounts:
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.
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.
We believe that this problem is resolved in the development version of rsconnect.
remotes::install_github("rstudio/rsconnect")
rsconnect:
1.1.0
Connect:2023.10.0-dev+216-g70573d7869
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