Can we deploy a website containing just .xml data files?
slodge-work opened this issue · comments
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:
- A Shiny app with
app.R
orserver.R
+ui.R
- R Markdown (
.Rmd
) or Quarto (.qmd
) documents.- A website containing
.html
and/or- A plumber API with
plumber.R
orentrypoint.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
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.
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
Line 40 in 21b1f53
- appMetadata
Line 10 in 21b1f53
- checkAppLayout
Line 83 in 21b1f53
- error
Line 111 in 21b1f53
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?
@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.
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.