You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have had problems understanding why our deployment pipelines sometimes created new apps even if the app already exists on Posit connect. Turns out that if you specify both appName and appId it seems like the appId is ignored if the user is not the current owner of the "old" application.
Dont know if this a bug or the documentation needs an update. Ideally i would also like a warning if both are specified so that, we are made aware of the behavior chosen.
Removing appname as an parameter for deployApp solved the problem for us, but others might be dealing with the same issues.
I suspect the issue comes from the call to appDeployments in R/deploymentTarget.R. Where providing the account for the accountFilter is the cause of the issue. (I am not familiar with the codebase so might be wrong here).
There are a number of issues tracking issues with re-deployment (especially by collaborators), including #1007.
I believe that appId should override appName as mentioned in the documentation, but will make sure that this is indeed the case as we resolve these related issues.
The development version of rsconnect uses appId as the primary way to identify existing content; could you test that redeployment targets the correct application in your environment?
We have had problems understanding why our deployment pipelines sometimes created new apps even if the app already exists on Posit connect. Turns out that if you specify both appName and appId it seems like the appId is ignored if the user is not the current owner of the "old" application.
This seems to be the opposite of the documentation for appid (https://rstudio.github.io/rsconnect/reference/deployApp.html):
´Use this to deploy to an exact known application, ignoring all existing deployment records and appName.´
Dont know if this a bug or the documentation needs an update. Ideally i would also like a warning if both are specified so that, we are made aware of the behavior chosen.
Removing appname as an parameter for deployApp solved the problem for us, but others might be dealing with the same issues.
I suspect the issue comes from the call to appDeployments in R/deploymentTarget.R. Where providing the account for the accountFilter is the cause of the issue. (I am not familiar with the codebase so might be wrong here).
The text was updated successfully, but these errors were encountered: