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

Cloud static outputs #825

Merged
merged 37 commits into from
May 9, 2023
Merged

Cloud static outputs #825

merged 37 commits into from
May 9, 2023

Conversation

mslynch
Copy link
Contributor

@mslynch mslynch commented Apr 28, 2023

  • Add support for deploying client-rendered static outputs to Posit Cloud
  • Save Cloud deployments with appId as the Cloud content id (instead of application id)
  • Introduce versioning to dcf files (needed to support backwards compatibility for old Cloud dcf files saved with appId as the application id

Resolves #824.
Resolves #821.

@mslynch mslynch marked this pull request as ready for review April 28, 2023 17:26
R/client-cloud.R Outdated Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
Copy link
Member

@hadley hadley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! Do you also want to add a news bullet briefly describing these changes?

R/deploymentTarget.R Outdated Show resolved Hide resolved
R/deployments.R Outdated Show resolved Hide resolved
R/http.R Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
R/deployApp.R Outdated Show resolved Hide resolved
R/deployApp.R Show resolved Hide resolved
R/deployApp.R Show resolved Hide resolved
R/deploymentTarget.R Outdated Show resolved Hide resolved
R/deployments.R Outdated
@@ -143,7 +143,10 @@ deploymentRecord <- function(name,
c(standard, metadata)
}

dcfVersion <- "1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hadley You had earlier decided to not make structural changes to the DCF files, making for simpler roll-forward/roll-back. Has your position changed?

In particular, how would the current CRAN release react to a versioned deployment DCF file?

Copy link
Member

@hadley hadley May 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should just ignore it; the metadata argument has always allowed you to add arbitrary additional columns which don't otherwise cause problems.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The meaning of one of the fields is changing, yes? What does this mean when we attempt to use those DCF files with an old rsconnect release?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooh, I think I get what you mean now — we're adding a version field that will allow us to do more versioning in the future, but there's no intent to add any backward incompatible changes at this time. The current goal is to make it possible to tell if applicationId means appId or contentId in existing deployments to cloud; contentId is substantially easier to work with and more meaningful on the server side, but we don't want to break existing deployment records that stored appId.

We considered renaming applicationId more generally (since rsconnect is not just about applications any more), but given that it's mostly an internal feature used by the IDE, we didn't think it was worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The situation that concerned me:

  1. Deploy (new) using CRAN rsconnect (or any version prior to this change).
  2. Re-deploy using this version of rsconnect (which upgrades the DCF file).
  3. Re-deploy using CRAN rsconnect.

Is the deployment DCF value of applicationId constant or does it change during this re-deploy sequence?

Copy link
Contributor Author

@mslynch mslynch May 1, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aronatkins The value of appId in the DCF file would change when deploying to cloud using this version of rsconnect (from the application id to the content id), so that scenario would break at step 3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hadley - You had mentioned trying to avoid this type of backwards incompatibility with the upcoming release.. has your opinion changed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reasoning: There's enough changing in rsconnect that the upcoming release will cause issues for some folks despite our efforts to avoid that. Folks will probably downgrade to the previous CRAN release until we can patch. We wanted to avoid situations where the downgrade caused its own problems.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ok because of its relatively limited scope — my other proposed change would've broken every single piece of metadata that you'd saved, which seemed a bit extreme.

R/deployments.R Outdated Show resolved Hide resolved
tests/testthat/test-deployments.R Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
R/client-cloud.R Outdated Show resolved Hide resolved
Copy link
Contributor

@toph-allen toph-allen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't actually see where deploymentRecordVersion is set. It looks like there used to be a variable named dcfVersion in deployments.R, but that change was removed in one of the commits that merged main into this branch.

I might just be overlooking something or searching for the wrong string, or misunderstanding the current state of things looking at the conversation. :)

@@ -94,7 +94,7 @@ createDeploymentTarget <- function(appName,
username,
account,
server,
version = 1) {
version = deploymentRecordVersion) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't actually see where deploymentRecordVersion is set.

@toph-allen That's right here.

@mslynch mslynch requested review from hadley and aronatkins May 5, 2023 16:27
Copy link
Member

@hadley hadley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

The only last thing you might want to do is to note any manual testing you did in a new .Rmd in tests/manual, so it's easier to remember in the future.

Copy link
Contributor

@aronatkins aronatkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wiring from application$id to application$application_id and changing the meaning of application$id is bound to throw us off in the future...

NEWS.md Outdated Show resolved Hide resolved
R/client-cloud.R Outdated
getApplication = function(outputOrApplicationId, deploymentRecordVersion) {
if (is.na(deploymentRecordVersion)) {
# In pre-versioned dcf files, outputOrApplicationId is the id of the application.
# TODO: consider removing support for this case a year after the release of 0.8.30
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update this TODO; the next release will be rsconnect-1.0.0.
How will we decide that it is "safe" to remove this block?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's never quite "safe" to remove this block – as long as someone has an old has an old deployment DCF file, this would break for them on removal. We don't have visibility into that, but I'm assuming we don't want to support this case forever.

application <- client$getApplication(target$appId, target$version)
taskComplete(quiet, "Found application {.url {application$url}}")

if (application$type == "static") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "static" notion is specific to Posit Cloud; does it belong here or with the call to uploadCloudBundle (where we already have cloud-specific logic)?

Related: Do we also need to call createRevision in the 404 path just below? applicationDeleted calls createApplication -- could you explain why this path explicitly creates a revision while the creation path does not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "static" notion is specific to Posit Cloud; does it belong here or with the call to uploadCloudBundle (where we already have cloud-specific logic)?

I think it really should go here because it creates the application. I originally had it there, but Hadley left a comment and convinced me otherwise.

Related: Do we also need to call createRevision in the 404 path just below? applicationDeleted calls createApplication -- could you explain why this path explicitly creates a revision while the creation path does not?

We don't – for static content, the revision is created implicitly when we create the application.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Thanks.

@mslynch mslynch merged commit bf0e209 into main May 9, 2023
@mslynch mslynch deleted the cloud-static-outputs branch May 9, 2023 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for deploying client-rendered static outputs to Posit Cloud Version the deployment dcf record
6 participants