By default, all automation steps and checks will run. But depending on the needs of your course, you can turn these on and off by going to the config_automation.yml file and switching options to yes or no.

The config_automation.yml file looks like this:

# Formatting Checks (run at pull request)
check-quizzes: yes
url-checker: yes
render-preview: yes
style-and-sp-check: yes
...

There are two main sets of automation steps and checks run: - .github/workflows/pull-request.yml : run upon opening a pull request - .github/workflows/render-all.yml: run upon changes being merged to the main branch

Pull request checks:

These actions are triggered upon a pull request being opened. It’s set up is in the file: .github/workflows/pull-request.yml/.

Check quiz formatting

In the config_automation.yml file it is set by:

check-quizzes: no

By default, it is set to no. But if you wish to create quizzes on Leanpub, you should set this to yes. This is not necessary if you only want quizzes for Coursera. Leanpub needs a particular format for it to upload correctly. This action will look for quizzes in a quizzes directory and check for these items. The outcome of these quiz checks will be printed to a GitHub comment on your pull request.

Check for broken URLs

In the config_automation.yml file it is set by:

url-checker: yes

GitHub actions runs a check on all the URLs upon creating a pull request to the main branch. If it fails, you can click on the output comment on your pull request that says “Download errors here”. This will give you a print out of the broken urls it found.

If the URL checker is failing on something that isn’t really a URL or doesn’t need to be checked, open the resources/ignore-urls.txt file and add that url exactly as it is specified in the error print out.

Preview rendering

In the config_automation.yml file it is set by:

render-preview: yes

After you open a pull request, a preview of the renders will be linked in a automatic comment on the pull request. Upon each commit these previews will re-render and edit the comment with the latest render.

These Github Actions are located in render-preview section of the pull-request.yml. These previews do NOT incorporate any changes influenced by any changes to the Docker image if the Dockerfile is also updated in the same pull request.

Spell checking

In the config_automation.yml file it is set by:

spell-check: yes

Github actions will automatically run a spell check on all Rmd’s and md’s whenever a pull request to the main branch is filed.

It will fail if there are more than 2 spelling errors and you’ll need to resolve those before being able to merge your pull request. Errors will be printed out on a GitHub comment on your pull request.

To resolve those spelling errors, click on the link with the errors on the autogenerated comment. Some of these errors may be things that the spell check doesn’t recognize for example: ITCR or DaSL. If it’s a ‘word’ the spell check should recognize, you’ll need to add this to the dictionary.

Go to the resources/dictionary.txt file. Open the file and add the new ‘word’ to its appropriate place (the words are in alphabetical order). Then commit the changes to resources/dictionary.txt to your branch and this should make the spell check status check pass.

Style code

In the config_automation.yml file it is set by:

style-code: yes

The styler package to all style R in all Rmds. Style changes will automatically be committed back to your branch.

Docker testing

In the config_automation.yml file it looks like:

docker-test: no

By default it is set to no which means it won’t run automatically unless you change this to yes. This is only relevant if you have your own Docker image you are managing for your course. If changes are made to Docker-relevant files: Dockerfile, install_github.R, or github_package_list.tsv, this will test re-build the Docker image. If it is successfully built, then it makes sense to merge it to main but the docker image will not be pushed to Dockerhub automatically. Follow these instructions to push your Docker image to Dockerhub.

Rendering actions

Upon merging changes to any Rmd or assets/ folder to main, the course material will be automatically re-rendered. By default, all rendering steps will be run. But depending on the needs of your course, you can turn these on and off by going to the config_automation.yml file and switching options to yes or no.

render-bookdown: yes
render-leanpub: yes
render-coursera: yes

For publishing to Leanpub, make sure that the render Leanpub option is set to yes: render-leanpub: yes. See more details about publishing to Leanpub, here.

For publishing to Coursera, make sure render Coursera option is set to yes: render-coursera: yes. See more details about publishing to Coursera, here.

Manually running rendering or checks

From time to time, it may be useful to manually re-trigger a particular GitHub action. Most of the GitHub Actions, particularly the rendering ones, can be re-run manually. See this article about how to manually re-run a GitHub Action.

Fixing broken GitHub Actions

GitHub action rendering or other GitHub actions may fail sometimes if the input is unexpected or for a number of other reasons. To investigate why a GitHub action has failed, go to Actions and click on the failed action. See this article for how to find this information.

See our FAQ’s section for the most commonly encountered errors and how to address them.

If you are unsure what the error message means and have trouble addressing it, please file an issue on the OTTR_Template repository to get help.