flash-services 0.3.3

The services that can be shown on a Flash dashboard.

The services that can be shown on a Flash dashboard. Includes the service update code and any custom templates not available in the core Flash package.

Documentation

Documentation is available on PythonHosted.

Available services

The following service definitions include the configuration options:

• codeship - for CI builds on Codeship

  • api_token (required)

  • project_id (required)

• coveralls - for coverage reporting on Coveralls (currently only supports open-source builds)

  • vcs_name (required - the name of the service the project is accessed via, e.g. 'github')

  • account (required - the name of the account the project is in, e.g. "textbook")

  • repo (required - the name of the project repository within that account, e.g. "flash")

  • ok_threshold (the minimum coverage level to show as an OK state, defaults to 80%)

  • neutral_threshold (the minimum coverage level to show as a neutral state, defaults to 50%)

• github - for project repositories on GitHub

  • api_token (required),

  • account (required - the name of the account the project is in, e.g. "textbook")

  • repo (required - the name of the project repository within that account, e.g. "flash")

  • branch (the name of the branch to show commits from, defaulting to the repository’s default branch, which is usually master).

• tracker - for projects on Pivotal Tracker

  • api_token (required)

  • project_id (required)

• travis - for public CI builds on Travis CI (.org).

  • account (required)

  • app (required)

• travis_pro - for private CI builds on Travis CI (.com)

  • account (required)

  • api_token (required - see Travis API docs for details)

  • app (required)

Writing a service

The idea behind this package is to make it easier to add new service providers to Flash. Each new service should subclass Service (or one of its more specific children, where appropriate) from the core.py file. The mix-in classes in auth.py can be used to implement authentication to the service API endpoint as needed (currently both header and query parameter token validation are supported).

Any service-specific partial templates (using the Jinja2 templating language) should be placed in templates/partials and service-specific client-side behaviour should live in a new function in the SERVICES object in static/scripts/services.js, keyed by the FRIENDLY_NAME of the service.