Introduction¶

After setting up build automation we also wanted it not to happen only when updating the documentation repository.

Besides hosting documentation, Elegant website also serves as a live demo of the current release. This meant, the website should be regenerated and updated every time when a documented is added or edited, and also when Elegant theme is updated.

Github and Travis doesn’t offer dependent builds out of the box, so the trick goes to ‘signal’ via a github token to trigger a Travis-CI build.

The technical solution¶

The approach goes via tweaking the ‘test validation’ .travis.yaml and adding some more steps:

The initial file (similar to the one in our previous article, but for running the ‘page build’ with latest repo checkout) looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# Copyright (C) 2017, 2018 Pablo Iranzo Gómez <[email protected]>

language: python
dist: trusty
sudo: required

python:
  - "3.5"

# prepare and move data for execution

before_install:
  - pip install -U pip
  - pip install -U setuptools
  - pip install -r tests/requirements.txt
  - pip install -r tests/test-requirements.txt
  - pip install peru
  - mkdir -p tests/themes/elegant
  - mv templates tests/themes/elegant/
  - mv static tests/themes/elegant/
  - cd tests && peru sync

script:
  - pelican content/ -o output/

Is then modified to add:

1
2
3
4
5

before_script:
  - npm install travis-ci

after_success:
  - node trigger-build.js

This installs Travis-CI utilities and runs a custom script ‘trigger-build.js’ with node, which in turn actually triggers Travis build.

The script, downloaded from Kamran Ayub blog has been edited to specify the ‘repo’ we will trigger and the name of the environment variable containing the token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

var Travis = require('travis-ci');

// change this
var repo = "Pelican-Elegant/documentation";

var travis = new Travis({
    version: '2.0.0'
});

travis.authenticate({

    // available through Travis CI
    // see: http://kamranicus.com/blog/2015/02/26/continuous-deployment-with-travis-ci/
    github_token: process.env.TRATOKEN

}, function (err, res) {
    if (err) {
        return console.error(err);
    }

    travis.repos(repo.split('/')[0], repo.split('/')[1]).builds.get(function (err, res) {
        if (err) {
            return console.error(err);
        }

        travis.requests.post({
            build_id: res.builds[0].id
        }, function (err, res) {
            if (err) {
                return console.error(err);
            }
            console.log(res.flash[0].notice);
        });
    });
});

As you can see, in line 14, it grabs the github token from environment variable TRATOKEN that we’ve defined in Travis-CI environment for the build.

This is similar to what we did in the documentation repo to push the built website to another repo.

With this solution in place, when a new commit is merged on ‘master’ branch on the ‘theme’ repo (elegant), Travis does get invoked to schedule a build on the documentation repo, thus, rendering the live website with latest templates.

Enjoy! Pablo

Like this post? Share on: Twitter ❄ Facebook ❄ Email

Pablo Iranzo Gómez opensource enthusiast and Lego fan doing some python simple programs like @redken_bot in telegram, etc