Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify download-edit-redeploy workflow #270

Closed
scottmmjackson opened this issue May 7, 2018 · 7 comments · Fixed by #709
Closed

Simplify download-edit-redeploy workflow #270

scottmmjackson opened this issue May 7, 2018 · 7 comments · Fixed by #709
Labels
deploy ⛹️ feature a feature request or enhancement

Comments

@scottmmjackson
Copy link
Contributor

Right now, it's possible to download a bundle, edit it, and redeploy it to the same endpoint using the following steps:

  1. Download the bundle using the Source Versions dialog and untar locally.
  2. Edit and redeploy using:
rsconnect::deployApp("content/path", server = "host", account = "username", appId = 1234)

Where 1234 is the ID of the downloaded app.

Things that make this less than awesome:

  • Finding the app id is confusing. A downloaded bundle reads app-<appId>-<bundleId>.tar.gz. There is no cue distinguishing app ID from bundle ID other than position.
    • The app ID is not included in the manifest; arguably it should not be, because the manifest identifies the content of the bundle and not the location where it is deployed.
  • This workflow goes to a core collaboration use case that's likely to be repeated many times by many people with varying levels of familiarity with R, RStudio, Shiny/RMarkdown, and RStudio Connect.
    • There might have to be IDE changes to get this to work as pleasantly as we'd like.
@jmcphers
Copy link
Member

Do the changes described in #268 (see last comment) sound like they'd do what you want?

@scottmmjackson
Copy link
Contributor Author

I'm not sure it does. FWIW I think we've come to a workaround, at least- documenting that collaboration requires duplicating the rsconnect folder from the first deployment.

@hadley hadley added feature a feature request or enhancement deploy ⛹️ and removed enhancement labels Feb 17, 2023
@hadley
Copy link
Member

hadley commented Feb 21, 2023

Are we sure we want to promote this workflow? I think ideally we'd encourage folks to share the code on github or similar?

@aronatkins
Copy link
Contributor

Agree that Connect is not a source-control system. There is still a case for simpler "publish to existing content" when you don't have the original rsconnect deployment records.

@hadley
Copy link
Member

hadley commented Feb 21, 2023

We may also want to reconsider the logic here:

rsconnect/R/deployApp.R

Lines 337 to 339 in 800a9eb

# write a deployment record only if this is the account that owns the content
if (is.null(application$owner_username) ||
accountDetails$username == application$owner_username) {

I'm pretty sure we want to always save the deployment record, even if you're updating someone else's content.

But we do want to preserve as a much as possible, probably including the previous account name.

@hadley
Copy link
Member

hadley commented Feb 22, 2023

And think about this code, which which looks up an appId from appName:

rsconnect/R/deployApp.R

Lines 707 to 714 in 8a8df23

if (is.null(target$appId)) {
# list the existing applications for this account and see if we
# need to create a new application
app <- getAppByName(client, accountInfo, target$appName)
} else {
# we already know the app's id, so just retrieve the rest of the metadata
app <- client$getApplication(target$appId)
}

@hadley
Copy link
Member

hadley commented Feb 22, 2023

Probably makes sense to tackle at the same time as #677

hadley added a commit that referenced this issue Feb 24, 2023
@hadley hadley closed this as completed in 9808693 Feb 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deploy ⛹️ feature a feature request or enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants