View on GitHub -

Buildtime Trend as a Service

Visualise what's trending in your build process

Download this project as a .zip file Download this project as a tar.gz file

Buildtime Trend as a Service Buildtime Trend as a Service

This project contains the files that offer Buildtime Trend as a service. The Buildtime Trend library powers this service.

Usage

Use the service available on Heroku

Clone the project and deploy it to Heroku

See instructions on the wiki on how to configure the service on Heroku.

Run it on your own server

python service.py

Remark : By default it will attach to port 5000, use environment variable PORT to override this.

More configuration options are available.

utils/start_worker.sh

A Celery compatible task queue service is required to use the task queue, see the task_queue config parameter in the configuration options section.

Components

Index page

Dashboard

Display a dashboard with Buildtime Trend charts

Remark : When visiting /dashboard (without parameters), an overview of all hosted projects is displayed.

Service usage statistics

Display a dashboard with Buildtime Trend service usage statistics

Shield badges

Generate a shield badges

Badge examples

Process Travis CI build log

Loads a Travis CI build log file, processes it and sends the data to Keen.io.

If last_build is not defined, only a single build will be processed, namely the one defined by first_build. If last_build is defined, it turns into batch mode : multiple builds will be processed : all builds from first_build to and including last_build will be scheduled to be processed. To limit the load on the worker, a delay is added to every next build. F.e. build #1 will be executed immediately, build #2 after x seconds, build #3 after x*2 seconds, build #n after x*(n-1) seconds. By default the delay is 3 seconds, but this can be configured with the multi_import.delay setting in config_service.yml or BTT_MULTI_DELAY env variable. The maximum number of builds that can be imported at once in batch mode is by default limited to 100. This can be configured with the multi_import.max_builds setting in config_service.yml or BTT_MULTI_MAX_BUILDS env variable.

OR

To trigger the service at the end of a Travis CI build, add this to your .travis.yml file:

    notifications:
      webhooks:
        # trigger Buildtime Trend Service to parse Travis CI log and send result to Keen.io
        - https://buildtimetrend.herokuapp.com/travis

When Buildtime Trend Service is triggered by a Travis CI notification, it will get the necessary parameters (repo name and build number) from the payload that is passed by Travis CI. This will trigger loading and parsing the Travis CI log of the corresponding build, the analysed data is stored in the Keen.io database.

Config file

Add a configfile named config_service.yml based on config_sample.yml to configure the way the service behaves.

Remark : Setting denied_repo takes precedence over allowed_repo, if a repo name matches a rule in denied_repo setting, the repo will be denied, even if it matches a rule in allowed_repo. Multiple entries are allowed, fe. :

buildtimetrend:
  denied_repo:
    - "my_name" # denying all repo names that contain my_name
    - "another_name/some_repo" # denies this specific repo

Remark : Setting denied_repo takes precedence over allowed_repo, if a repo name matches a rule in denied_repo setting, the repo will be denied, even if it matches a rule in allowed_repo. Multiple entries are allowed, fe. :

buildtimetrend:
  allowed_repo:
    - "my_name" # allowing all repo names that contain my_name
    - "another_name/some_repo" # allows this specific repo

Remark : the account token should be the one of the user who created the repo on Travis CI.

It can also be defined with the TRAVIS_ACCOUNT_TOKEN environment variable.

buildtimetrend:
    task_queue:
        backend: "" # backend type fe. amqp, redis, ...
        broker_url: "" # backend instance url, format : transport://userid:password@hostname:port/virtual_host

If task_queue is defined, this will be enable using a worker to execute heavy tasks. To disable using a worker, remove the task_queue directive from the config file.

The broker_url can also be defined with several environment variables :

The environment variables are checked in this order, the first one that is defined, will be used. The backend type (amqp, redis, ...) associated with the environment variable will be set automatically.

buildtimetrend:
    multi_import:
        max_builds: 100 # maximum number of builds allowed in one batch
        delay: 3 # number of seconds between the start of each build

Setting max_builds is 100 by default, and can also be set with the BTT_MULTI_MAX_BUILDS environment variable. Setting delay is 3 seconds by default, and can also be set with the BTT_MULTI_DELAY environment variable.

Dependencies

See requirements.txt for package names and versions.

Bugs and feature requests

Please report bugs and add feature requests in the Github issue tracker.

Contribute

If you want to contribute to make Buildtime Trend even better, check out the contribution page. We are looking for testers, developers, designers, ... and what more. Contact us if you want to help out.

Donations

You can support the project by making a donation. The donations will help pay for the hosting and support further development.

Credits

For an overview of who contributed to create Buildtime trend, see Credits.

Contact

Website : https://buildtimetrend.github.io/service

Mailinglist : Buildtime Trend Community

Follow us on Twitter, Github and OpenHub.