As part of my never-ending quest to deploy documentation better, I’ve made yet another tweak to my scripts that deploy R vignettes or Rmarkdown documents to the gh-pages branch of my github repositories via Travis-CI.

The script from Robert Flight that’s provided the basis for most of this work does something specific to update the web facing branch of the repository. It would:
1. Create a blank repository
2. Add the requisite files to the repository
3. Add and commit them to the repo
4. Force the repo to overwrite the gh-pages branch

This had the unfortunate consequence of losing the history of what was previously hosted on the branch and could not tell me what commit to my development branches was responsible for a version of the docs. It took a little bit of playing but the revised script now:
1. Clones the gh-pages branch
2. Adds the requisite files into the reports
3. Add and commit them to the repo
4. Push the changes

Using an environment variable ($TRAVIS_COMMIT) the commit message is the commit ID for the latest commit in the build that occurs on Travis, making it very easy to see what changes triggered a documentation update.

This version is designed to extract generated vignettes, but the principal holds for any generated files.


rm -rf out || exit 0;
mkdir out;



for files in '*.tar.gz'; do
tar xfz $files

git clone out --branch gh-pages
cd out
git config "stephs-travis"
git config "travis"

for files in '../RMSFTDP/inst/doc/*.html'; do
cp $files .

git add .
git commit -m "$TRAVIS_COMMIT"
git push --quiet $FULL_REPO

Posts in this series

  1. Automated documentation hosting on github via Travis-CI
  2. Auto-deploying documentation: multiple R vignettes
  3. Auto-deploying documentation: FASTER!
  4. Auto-deploying documentation: Rtraining
  5. Auto-deploying documentation: better change tracking of artefacts

Auto-deploying documentation: better change tracking of artefacts

3 thoughts on “Auto-deploying documentation: better change tracking of artefacts

What do you think?