This workflow renders some Rmarkdown via its (custom) site generator and deploys the result. Suitable for:
Blogdown websites (experimental)
any other site generators that can be called via rmarkdown::render_site() and returns the path to the rendered assets (experimental).
website(IDENTIFIER = "Render and Deploy RMarkdown Website",
deploy = list(master = ghpages()))[character(1)]
giving the name of the action or workflow block.
Used:
as an informative label on GitHub.com,
in the needs fields of other action blocks to model the workflow graph,
in the resolves fields of other workflow blocks to model the workflow graph.
[list(1)]
giving the name of the branch to deploy from, and the function to deploy with.
A list as specified in the workflow argument to use_ghactions().
This action requires a Docker image called literally repo:latest in github/workspace.
See vignette for details.
Use build_image() to create one in a prior action.
This action or workflow requires that you bring-your-own-dockerfile (byod).
There has to be a Dockerfile at the root of your repository.
It's easy to set one up using use_dockerfile().
To learn more, consider the vignette.
Rmarkdown site generators can write to arbitary directories, and these output directory can be set in a number of places.
Happily, rmarkdown::render_site() (invisibly) returns the path to the rendered assets.
The website() workflow automatically retrieves this path, and writes it to a special .deploy_dir text file.
Downstream deploy actions such as ghpages() default to deploying from the directory specified in such a .deploy_dir.
This isn't a terribly elegant way of doing this, but because each action runs it's own container, and only the github/workspace directory persists between them, it is currently the only way to pass the path to the deploy actions.
Users will probably never see the .deploy_dir file, and need not worry about it.
Other workflows: fix_docs
Other byod: rscript_byod