Can we deploy a website containing just .xml data files?

[slodge-work]

I've just upgraded one of our existing configuration file projects/deployments from rsconnect 0.8.29 to 1.1.0, and have hit this error:

! Cancelling deployment: invalid project layout.
ℹ Expecting one of the following publication types:

1. A Shiny app with app.R or server.R + ui.R
2. R Markdown (.Rmd) or Quarto (.qmd) documents.
3. A website containing .html and/or .pdf files.
4. A plumber API with plumber.R or entrypoint.R.

I can't quite spot where this change happened.... the code has been around a few times 6 or so months ago:
https://github.com/rstudio/rsconnect/blame/21b1f538b1767122a12bc2dbcf0ba74704dea0f1/R/appMetadata.R#L116 - but I've not managed to spot when this lint/check functionality actually changed.

We find it really useful to deploy some static configuration files (in this case just a single xml file) as configuration - these are source controlled configurations deployed from our CI/CD pipelines.

I appreciate we could switch to pins instead for this data - but this will require some additions, including auth changes in our CI/CD code... so I thought I'd ask first if there's any way (e.g. via us sending a PR) that we can open up this option - e.g.

• adding .xml as an option in https://github.com/rstudio/rsconnect/blob/21b1f538b1767122a12bc2dbcf0ba74704dea0f1/R/appMetadata.R#L103C1-L104C1:
• or adding a flag to writeManifest to skip this check

[aronatkins]

A pin is really an index.html file alongside the data files. If you were to add a dummy index.html file, you could get a human+browser-friendly content page alongside your XML data, but I accept that you may not want to include this additional HTML.

Have you tried writeManifest(appMode = "static")? That's a recent change that lets you force the type of content if the inferred type is incorrect. You may also want to provide appPrimaryDoc to indicate the file that will be served when your content URL is directly visited.

[slodge-work]

Thanks.

Yes - have looked at the new appMode param and we'd be happy to add that to our scripts.

However, currently writeManifest calls appMetadata which calls into checkAppLayout without passing in appMode. checkAppLayout then fails with the "invalid project layout" error from the issue.

• writeManifest

  rsconnect/R/writeManifest.R

  Line 40 in 21b1f53

  appMetadata <- appMetadata(

• appMetadata

  rsconnect/R/appMetadata.R

  Line 10 in 21b1f53

  checkAppLayout(appDir, appPrimaryDoc)

• checkAppLayout

  rsconnect/R/appMetadata.R

  Line 83 in 21b1f53

  checkAppLayout <- function(appDir, appPrimaryDoc = NULL) {

• error

  rsconnect/R/appMetadata.R

  Line 111 in 21b1f53

  cli::cli_abort(c(

A possible fix here is to pass the appMode in to checkAppLayout - and to ignore the satisfiedLayouts check in this case? ... or maybe there's just no point in calling checkAppLayout when appMode has been set?

[aronatkins]

@slodge-work Ah. Thanks for digging. You're absolutely right.

@hadley Do you have any thoughts about checkAppLayout()? It wants to present a client-generated error when the set of files is not a known structure. As demonstrated by this issue, sometimes that check is too strict.

Options that come to mind:

• ignore the layout check when appMode has been provided -- the user is forcing the content type, and rsconnect should allow any set of files
• allow standalone XML (and other data?) files (just like HTML)
• convert the layout check into a warning
• remove the layout check entirely

As I think about this problem more, I'm leaning towards removing the layout check. Things like Quarto pre-render scripts are changing what is required for a valid deployment, and we will encounter more scenarios where folks want to deploy new combinations of file types.

[hadley]

Yeah, removing the client side layout check makes sense to me — it's really the responsibility of the server to complain if you give it something that it doesn't know how to serve.