Skip to content
The services that can be shown on a Flash dashboard.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs
flash_services
tests
.checkignore
.gitignore
.pylintrc
.travis.yml
LICENSE
README.rst
conftest.py
requirements.txt
setup.py

README.rst

Flash Services

PyPI Version Travis Build Status Test Coverage Other Code Issues ISC License

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%)
  • gh_issues - for issues and PRs in 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")
    • neutral_threshold (the maximum half life to show as a neutral state, in days, defaults to 30)
    • ok_threshold (the maximum half life to show as an OK state, in days, defaults to 7)
  • ghe_issues - for issues and PRs in project repositories on GitHub Enterprise installations
    • 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")
    • neutral_threshold (the maximum half life to show as a neutral state, in days, defaults to 30)
    • ok_threshold (the maximum half life to show as an OK state, in days, defaults to 7)
  • 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)
  • github_enterprise - for project repositories on GitHub Enterprise installations
    • 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)
  • jenkins - for CI builds on Jenkins instances.
    • username (required)
    • password (required)
    • root (required - the root URL for the Jenkins instance)
    • job (required - the name of the job, which must match the job URL)
  • 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).

  • Create a new Service subclass, or use one of the pre-provided subclasses for continuous integration or version control systems;
  • Use the mix-ins from auth.py and core.py to add any required authentication, custom root setting and/or health thresholds;
  • Define any additional REQUIRED configuration parameters on the class (required parameters from its superclasses will be added automatically);
  • Set the appropriate TEMPLATE for it (if not a standard template, add it to templates/partials - use the Jinja2 templating language), and note that the service data will be exposed to the template as service_data for the initial load data binding and for clients without JavaScript;
  • Set the FRIENDLY_NAME, for display in the top-left of each pane, if not the same as the class name;
  • Register the service in both SERVICES objects, using the same key:
    • in Python (__init__.py); and
    • in JavaScript (static/scripts/services.js, where any service-specific client-side behaviour should also be placed).
You can’t perform that action at this time.