feat: add content migrate-to-connect-cloud - #838
Open
samperman wants to merge 1 commit into
Open
Conversation
Point a directory's local deployment record at an existing Posit Connect Cloud content item, so the next deploy from that directory updates that item instead of creating a second one. Connect Cloud cannot look content up by name, so the local record is the only way back to a content item; without one, deploying content that already exists there duplicates it. Nothing is copied and no bundle is uploaded. The record that was migrated from is removed, leaving the directory with one deployment target rather than two; `--from-server` chooses which record to migrate when the store covers several servers, and `-o/--overwrite` replaces an existing Connect Cloud record. Records are keyed by account, and a deploy refuses content owned by another account, so a record written under the wrong account would be silently useless. Migration therefore requires the content's owning account to be the one being targeted and names it when it is not. With no local record at all the record is reconstructed from the content, with app mode `unknown`, which `validate_app_mode` already tolerates. Fixes #826
|
vrsarah
reviewed
Aug 14, 2026
| target rather than two; pass `--from-server` to choose which record to migrate | ||
| when there are several. | ||
|
|
||
| ## Unreleased |
vrsarah
reviewed
Aug 15, 2026
| Only records for other servers are candidates: a Connect Cloud record is | ||
| what this migration produces, so treating one as a source would delete the | ||
| result. With no `from_server` a lone record is taken, and several are | ||
| reported rather than picked between. |
There was a problem hiding this comment.
Is this safe when the lone record is Connect's deployment record?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
Point a directory's local deployment record at an existing Posit Connect
Cloud content item, so the next deploy from that directory updates that
item instead of creating a second one. Connect Cloud cannot look content
up by name, so the local record is the only way back to a content item;
without one, deploying content that already exists there duplicates it.
Nothing is copied and no bundle is uploaded. The record that was
migrated from is removed, leaving the directory with one deployment
target rather than two;
--from-serverchooses which record to migratewhen the store covers several servers, and
-o/--overwritereplaces anexisting Connect Cloud record.
Records are keyed by account, and a deploy refuses content owned by
another account, so a record written under the wrong account would be
silently useless. Migration therefore requires the content's owning
account to be the one being targeted and names it when it is not. With
no local record at all the record is reconstructed from the content,
with app mode
unknown, whichvalidate_app_modealready tolerates.Fixes #826
Type of Change
Approach
This follows the patterns established by rstudio/rsconnect#1353 and rstudio/rsconnect#1358
Automated Tests
Unit tests exist, integration tests are scheduled but will happen after this merges.
Directions for Reviewers
These steps can be used to verify it works locally:
uv run rsconnect add -n shinyapps -A <shinyapps-account> -T <token> -S <secret>uv run rsconnect add -n cloud --connect-cloud -A <cc-account># opens a browseruv run rsconnect deploy shiny ./my-app -n shinyappsuv run rsconnect content migrate-to-connect-cloud ./my-app -n cloud --content-id <content-id>uv run rsconnect info ./my-appuv run rsconnect deploy shiny ./my-app -n cloudThis tool will also create a new deployment record if its missing. This test can be done without shinyapps.io or content migration in Connect Cloud.
uv run rsconnect deploy shiny ./my-app -n cloudrm -rf ./my-app/rsconnect-pythonChecklist
rsconnect-python-tests-at-nightworkflow in Connect against this feature branch.