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

Simply deploymentTarget() logic #666

Merged
merged 22 commits into from
Feb 14, 2023
Merged

Simply deploymentTarget() logic #666

merged 22 commits into from
Feb 14, 2023

Conversation

hadley
Copy link
Member

@hadley hadley commented Feb 13, 2023

This PR went a bit out of control, but it does two main things:

  1. Introduces a new 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 that resolveAccount() was previously used.
  2. Uses findAccounts() and some thought to simplify deploymentTargets(); 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.

@@ -214,25 +71,3 @@ createDeploymentTarget <- function(appPath,
server = server
)
}

findAppId <- function(appPath, appName, account, server, username) {
Copy link
Member Author

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(
Copy link
Member Author

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)) {
Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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:

Screenshot 2023-02-13 at 16 34 47

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.

Copy link
Member Author

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.

Copy link
Member Author

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 ||
Copy link
Member Author

@hadley hadley Feb 13, 2023

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.

@hadley hadley marked this pull request as ready for review February 13, 2023 19:25
#' 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
Copy link
Contributor

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.

Copy link
Member Author

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

R/deployApp.R Outdated Show resolved Hide resolved


# if appTitle specified but not appName, generate name from title
if (is.null(appName) && !is.null(appTitle) && nzchar(appTitle)) {
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Member Author

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.

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.

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.

R/acccount-find.R Outdated Show resolved Hide resolved
stopWithMultipleAccounts(name)
if (length(configFile) == 0 || !file.exists(configFile))
stop(missingAccountErrorMessage(name))
fullAccount <- findAccount(name, server)
Copy link
Contributor

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.

Copy link
Member Author

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.

@hadley hadley merged commit 2dec764 into main Feb 14, 2023
@hadley hadley deleted the deploymentTarget-errors branch February 14, 2023 14:26
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.

3 participants