-
Notifications
You must be signed in to change notification settings - Fork 84
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
Cloud static outputs #825
Conversation
* Basic way to test with mocked http * Tests for cloud deploys of connect and static apps * Provide a way for individual tests to add responses
If output is in trashed or archived state, set it to active
cloud static outputs branch
There was a problem hiding this 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/deployments.R
Outdated
@@ -143,7 +143,10 @@ deploymentRecord <- function(name, | |||
c(standard, metadata) | |||
} | |||
|
|||
dcfVersion <- "1" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
- Deploy (new) using CRAN rsconnect (or any version prior to this change).
- Re-deploy using this version of rsconnect (which upgrades the DCF file).
- Re-deploy using CRAN rsconnect.
Is the deployment DCF value of applicationId
constant or does it change during this re-deploy sequence?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Hadley Wickham <hadley@posit.co>
…s id and application id as application_id
… removing backwards compatibility
There was a problem hiding this 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) { |
There was a problem hiding this 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.
@toph-allen That's right here.
There was a problem hiding this 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.
There was a problem hiding this 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...
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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") { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
callscreateApplication
-- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Thanks.
Resolves #824.
Resolves #821.