Blogdown, travis and branches management

This blog is a static hugo blog, generated with the amazing R package blogdown. At first shot, i decided to locate the working documents in a different directory as the published hugo site, allowing me to separate commits to the sources from commits of compiled files.

But thoose two repo were a problem : things were not centralised enough for me, and i wanted to push on github only the files i’m working on : commiting compiled files is not realy a good practice.

So i switched to a different framework : Using travis and a src branch, i’m now able to centralise everything in one repo, and separate my sources (in the src branch) and the compiled files (in the master branch, allowing github to publish on, while NOT doing the compilations myself. The .travis.yml files allows me to avoid publication of the new version of the site if there are errors in compilation of my .Rmd posts, wich is nice too. Last but not least, continuous integration exempt me for bothering with compilation process everytime i write a new post, but still allows me to look at the log if something failed.

Finaly, even if the correct configuration of travis deployment was a little tricky, i managed to gain some time of compilation at every post. Remind that if you want travis to also cache the compiled .Rmd files, you should add some folders in the cache travis option, see blogdown documentation.

The workflow is now the following :

1° My local copy of the repo is and stays on the src branch. Just add .Rmd or .md files into the relevant directory of the blogdown/hugo architecture 2° Compile and retry your article until it’s neat for you. 3° Commit and push to the github src branch.

And that’s all. Travis will pick-up my commit, compile the .Rmd files, compile the Hugo static website and push the result to the master branch, the branch that is avaliable though the address. No need to compile localy and then push compiled files.

If the site building fails on travis, i get an email and my changes dont even make it to the website. This way, i’m sure that only working changes can be commited to the website.

Using the caching mecanisme on travis is not trivial : If you use a lot of R package, you better install them from source since only thoose packages can be stored in chache. Packages installed via r_binary_packages will be reinstalled everytime..

I still need to understand how blogdown caches the rendered content of .Rmd files to be able to store the relevant folders on travis as well, to decrease the execution time (and dont re-compile old posts everytime…)

comments powered by Disqus