-
Notifications
You must be signed in to change notification settings - Fork 81
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
Simply deploymentTarget()
logic
#666
Conversation
* Eliminates need for `resolveAccount()` in most places * Delete now unused `stopWith*()` functions * Use shared documentation
@@ -214,25 +71,3 @@ createDeploymentTarget <- function(appPath, | |||
server = server | |||
) | |||
} | |||
|
|||
findAppId <- function(appPath, appName, account, server, username) { |
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 is no longer needed because either we are deploying for the first time, in which case the appId
will be NULL
, or we're deploying for the second time, in which case we take the appId
from the previous deployment.
appDeployments$server | ||
) | ||
} | ||
appDeployments <- deployments( |
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 is a change in behaviour — now we consider only deployment which match the suppled, appName
, account
and server
. Previously (I think) supplying either server
or account
always generated a new deployment.
|
||
|
||
# if appTitle specified but not appName, generate name from title | ||
if (is.null(appName) && !is.null(appTitle) && nzchar(appTitle)) { |
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 is now only done on first deploy as documented. And I'm pretty sure the previous behaviour was incorrect as it meant that setting a new appTitle
would generally result in publishing a new app, rather than updating an existing app.
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.
Could you check what values are provided by the IDE? Its conventions have changed over time. In particular, what happens when going through the "Other Destination" workflow? Is that different from a "republish" workflow?
I don't recall what of name/title is given by the IDE. It would be good to capture that expectation.
We'll probably want to retest a handful of "new deployment" versus "overwrite deployment" workflows. CC @ChaitaC
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.
Here's what I see in the "Other destination" dialog — it like the UI allows you to choose the appTitle
, which appears to be auto generated from the doc name:
It's not clear what it users for the appName
. I'll need to do some more exploration.
The republish dialog only allows me to change which files are published.
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.
Note that the id also uses the output of applications()
to find the appId
based on the appName
, so that even if deployments()
is empty, it'll still attempt to update an existing bundle.
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've made an issue #669 to track logging more information so it's easier to verify this. I'll do that in a separate PR because this one is already big.
# TODO(HW): move this logic into deploymentTarget | ||
# if there's no new title specified, load the existing deployment record, if | ||
# any, to preserve the old title | ||
if (is.null(title) || is.na(title) || length(title) == 0 || |
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.
saveDeployment()
is only called from deployApp()
where title
is the appTitle
returned by deploymentTitle()
, so I moved the logic there.
#' then this parameter can be omitted. | ||
#' @param server Server name. Required only if you use the same account name on | ||
#' multiple servers (see [servers()]) | ||
#' @inheritParams deployApp |
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 roxygen documentation for inheritParams
(https://roxygen2.r-lib.org/articles/reuse.html) should contain additional examples showing which parameter documentation is inherited (only the overlapping arguments), and how one would combine inheritance with replacement / additional documentation.
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.
Doc issue at r-lib/roxygen2#1465, and a better long form explanation at https://r-pkgs.org/man.html#inheriting-arguments
|
||
|
||
# if appTitle specified but not appName, generate name from title | ||
if (is.null(appName) && !is.null(appTitle) && nzchar(appTitle)) { |
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.
Could you check what values are provided by the IDE? Its conventions have changed over time. In particular, what happens when going through the "Other Destination" workflow? Is that different from a "republish" workflow?
I don't recall what of name/title is given by the IDE. It would be good to capture that expectation.
We'll probably want to retest a handful of "new deployment" versus "overwrite deployment" workflows. CC @ChaitaC
@@ -0,0 +1,348 @@ | |||
# Standalone file: do not edit by hand |
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.
One of your other PRs is pulling in rlang
; does this file go away with an rlang
dependency?
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.
We haven't yet standardised this interface, so we're currently vendoring it into every package where we use it. I think it's worth the cost, because it makes input validation so much more pleasant. At some point once we provide an exported interface, we'll be able to remove from this and other packages.
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.
Upon a read-through, I like these changes. We should probably make sure we put these changes through QA, but if there's more coming down the pike, maybe it makes sense to bundle them and have @ChaitaC look at them together.
stopWithMultipleAccounts(name) | ||
if (length(configFile) == 0 || !file.exists(configFile)) | ||
stop(missingAccountErrorMessage(name)) | ||
fullAccount <- findAccount(name, server) |
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.
Wrapping all that logic up into a single function makes me v happy.
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.
Me too! It also always bugged me that I had to supply both name
and server
even though all the servers I publish to have the same username.
This PR went a bit out of control, but it does two main things:
findAccounts()
function that has extensive messaging to help you when an account isn't found (this fixes a pet peeve of mine). This is now used everywhere thatresolveAccount()
was previously used.findAccounts()
and some thought to simplifydeploymentTargets()
; I don't think the logic is completely the same but I think it should be close and it's now much much easier to reason about. I've updated the documentation to describe this new logic, and in general how updating works.Sorry this is so big, and I'm happy to discuss in real-time if you think that would be useful.