Dependency installation

Usage

First the timestamp recording needs to be initialised :

source /path/to/init.sh

This script will detect the location of the build-trend script folder,
adds it to the PATH and cleans logfiles of previous runs.
Executing the init script with source is required to export environment variables to the current shell session.

Because the script dir is added to PATH, no path needs to be added
when logging a timestamp :

timestamp.sh event_name

This will log the current timestamp to a file and display it on STDOUT.
Repeat this step as much as needed.

When all build stages are finished, run

analyse.py

which will analyse the logfile with timestamps and print out the results.
The analyse.py script will calculate the duration between the timestamps and add those to a file with the analysed data of previous builds.
When the analysis script encounters the end timestamp, it will stop analysing the timestamp file and return the duration of the build stages. Possible event names ending the analysis are : end, done, finished or completed.

Optionally timestamp.sh end can be run before analyse.py, but analyse.py adds the end timestamp automatically. The end timestamp can be useful if analyse.py is not immediately run after the monitored build process finishes.

When Keen.io is enabled, the data will be sent to your Keen.io project for analysis.

When run on Travis CI, it will automatically add build/job related info.
Parameter -m native will store data in xml format. It is recommended to use Keen.io to store data, see below for details.

To generate a graph from previous builds, run

generate_trend.py

It will take the file with analysed data generated by the analyse script and turn it into a trend graph and saves this graph.
Parameter --mode=native will create a trend using Python matplotlib. It is recommended to use Keen.io to generate graphs, see below for details.
If Keen.io is enabled, generate_trend.py can be run without parameters.

Use the sync-buildtime-trend-with-gh-pages.sh script when you run it as part of a Travis CI build. See below for details.

Store build time data in xml (native mode)

(It is recommended to use Keen.io to store data and generate trends, see below)

To store data in xml, native mode needs to be enabled. The xml file is stored in dashboard/buildtimes.xml by default.

add keen_read_key (see Keen.io section above, or generate a scoped read key with get_read_key.py project_name (project_name should be the same as the project_name used to store the data, this is usually the git-repo name, fe. buildtimetrend/python-client)

add project_name : repo name is a good default, but it can be custom project name as well, this is only used as title on the webpage. It is not used to collect data.

Browse to dashboard/index.html, this should display the trends

If you are building a Github repo on Travis CI, and you have gh-pages branch, you can use the script mentioned below to automatically add the right files and create the config file.

Integrate with Travis CI

You can integrate Buildtime Trend with your build process on Travis CI :
install and initialise the buildtime trend scripts, add timestamp labels, generate the trend
and synchronise it with your gh-pages branch.

All you need is a github repo, a Travis CI account for your repo and a gh-pages branch to publish the results.

You also need to create an encrypted GH_TOKEN to get write access to your repo (publish results on gh-pages branch) :

Run sync-buildtime-trend-with-gh-pages.sh in after_script to report the gathered timestamps with the result of the build in $TRAVIS_TEST_RESULT, which comes available in after_{success|failure}. after_script is executed regardless of the build result, so after both after_success and after_failure.