refactor GHA book build for speed and to support dataone package

[mbjones]

The DataONE package (dataone) is not successfully being installed in the current book build due to system library incompatibilities. In addition, the book build is really long (at times 30-60 minutes), which seriously impedes writing flow. Finally, much of the logic of the build is an shell script that originated before many of the modern and maintained Actions were created, so it would be good to remove it in favor of putting the whole build in GHA. Refactor the book to:

• [x] Support dataone and other libraries that have system requirements outside of the ordinary
• [x] Refactor the workflow to only check out repos once, in the github actions workflow
• [x] Set the branch to be built at the top of the script in an environment
• [x] Refactor to move _build_bookdown.sh to inside of the GHA workflow
  • [x] Remove the nceas-training checkout
  • [x] Don't hardcode the BRANCH in the script
  • [x] Move the quarto render to inside the GHA workflow @hdolinh
  • [x] Copy the built book to public inside the GHA workflow @hdolinh
• [x] Use a cache for the R package installs to speed up the build
• [x] Use linux binary R packages where possible to speed up the build
• [x] Update all actions to current versions to make use of bug fixes and features
  • [x] quarto setup @hdolinh
  • [x] Deploy to GitHub Pages @hdolinh
• [ ] Examine whether we still want to use gh-pages with force pushes, given newer approaches that are available
• [ ] Re-examine the third part action for deployment -- might be more direct with quarto-publish, TBD

[mbjones]

Started implementation on this, and completed most of it. The cached build now takes about 4 minutes, and installs the dataone requirements. The full build now uses the Posit binary package repository, which massively speeds up the deploy. Some other changes:

• dataone requirements now in place
• repository checkout now includes both the repro-research-course repo and the nceas-training repo, based on a BRANCH env var at the top of the workflow
• Use binary packages from Posit
• Added caching to R package install. Unless the package list changes, packages can be pulled straight from cache
• Upgraded several actions in use to latest version (more to do here)
• Refactored the workflow to no longer use r-lib/actions/setup-r-dependencies
  • This was the root of the problem with the system library conflicts. This action uses the pak package for binary installs, which is not compatible with some of the libraries we needed. I opted to remove this altogether, and instead use a normal remotes::install_deps() install. This, combined with the use of the Posit Ubuntu binaries and a clean caching step both eliminated the problems in the build and sped it up by a factor of 10.
• Started elimination of _build_bookdown.sh script. Still need to refactor quarto render and file copy.

While not everything is complete here, its a lot closer to what we need, so I'm merging what I have now in the develop branch into main at sha d16918dff954e. We can return to the other items and refactoring the rest of the _build shell script later.

One other item to add in:

• [ ] Refactor to support multiple parallel jobs in the workflow, one for the R-based book, one for the python scalable-computing book
  • Now that we are using quatro for both, it should be possible to reuse the build workflow rather than repeating it -- the only difference is whether R or python is installed first; judicious use of a cached venv should help make that fast too
    • It should be possible to make this dependent on code changes so only the parts of the workflow needed to be run are run at each call

[mbjones]

Watching the build, I see that another source of slow turnaround is the async publication to GutHub pages as a separate build step. It looks like it is spending all of its time uploading a large artifact file that has all of the books built over time. There would be much faster ways to do this if we deployed locally, by only building and deploying new materials, and keeping older materials the same as they were originally. And this could be sped up by using rsync rather than an entire artifact file. I'll try to come back to this part of the deploy later:

• [ ] Reduce size of the upload to gh-pages by using rsync, or eliminate that stage of the workflow altogether

[hdolinh]

Refactored the build so that branch name no longer has to be hardcoded. Instead it's sent from nceas-training http repo dispatch request