clarify what purpose actions can serve (actions vs workflows)

with the new GitHub Actions, a more traditional yml-based workflow definition is now available and crucially you can share a container across many steps. I'm guessing it would make most sense (if we were to use GitHub Actions for CI at all as per #325) to model GitHub actions on the already existing *.yml for Azure Pipelines. (Some very few changes appear to be necessary).

Such a setup would obviate the need for a bunch of separate actions (and containers) for many of those steps (build, check, covr, etc.). They always were a bit of a pain and caused some unnecessary overlap in maintenance and performance.

There are still actions (host/js and container-based) in the new GitHub actions, and they offer and attractive way to factor out shared parts of *.yml workflows.

I'm just not sure what actions should be saved.

Perhaps some obvious examples include those that have nothing to do with r, such as publishing to GitHub pages #221.

CD of packages

Other actions such as pkgdown, document could also still be used but in so far as they depend on the R environment (they both do), this requires that the "main" Azure-Pipelines-like workflow always installs dependencies to GITHUB_WORKSPACE. Even so, because these actions would have to ship with their own containers, they'd be subtly and needlessly different, causing a lot of problems. We might be better off just packing these into the *.yml workflow, all running in the same container.

CD for non-package projects

Here separate actions could be used, but we might also (as so far on Travis) just base this off of the *.yml workflow and just skip the unnecessary steps/jobs

Or maybe create a separate *.yml for R Markdown projects?

For anything involving rsconnect::deploy_() we also again depend heavily on the R environment (because of the underlying packrat magic).

Other Workflow Automation

testing reprexes might be nice: https://github.com/r-lib/ghactions/issues/328

maxheld83 / ghactions