Zeus

This project is under development.

Zeus is a frontend and analytics provider for CI solutions. It is inspired by the work done at Dropbox on Changes.

The initial version aims to support Travis CI via GitHub, including:

• xunit
• code coverage
• artifacts (e.g. from py.test --html)

Requirements

• Python 3 (3.6+)
• Node
• Postgres 9.4+

Setup

mkvirtualenv zeus --python `which python3`
make
zeus init

Bootstrap the database (see Makefile for details):

make reset-db

Finally, launch the webserver:

zeus devserver

# or alternatively, with workers:
zeus devserver --workers

Getting some data

$ zeus repos add https://github.com/getsentry/zeus.git

Once you've authenticated, give yourself access to the repository:

$ zeus repos access add https://github.com/getsentry/zeus.git [you@example.com]

Additionally, you can generate some mock data:

$ zeus mocks load-all

Layout

zeus
├── setup.py                // server dependencies
├── zeus                    // server code
|   ├── artifacts           // artifact handlers
|   ├── api
|   |   ├── resources       // api endpoints/resources
|   |   └── schemas         // api serializer/schemas
|   ├── cli                 // command line utilities
|   ├── models              // database schema
|   ├── storage             // file storage implementations
|   ├── tasks               // async task definitions
|   ├── vcs                 // version control system implementations
|   └── web                 // server-rendered web views
├── templates               // server-rendered templates
├── public                  // general static assets
├── package.json            // web client dependencies
└── webapp                  // web client
    ├── actions             // redux actions
    ├── components          // react components
    ├── reducers            // redux reducers
    ├── routes.js           // routes (react-router)
    └── pages.js            // react components (pages)

Data Model

• Most models contain a GUID (UUID) primary key.
• Some generalized models (such as ItemStat) are keyed by GUID, and do not contain backrefs or constraints.
• Access is controlled at the repository level, and is generally enforced if you use the {ModelClass}.query utilities.

zeus
├── ApiToken
|   └── ApiTokenRepositoryAccess
├── Hook
├── Repository
|   ├── RepositoryAccess
|   ├── ItemOption
|   ├── Build
|   |   ├── ItemStat
|   |   ├── Source
|   |   └── Job
|   |       ├── Artifact
|   |       ├── FileCoverage
|   |       ├── ItemStat
|   |       └── TestCase
|   |           ├── Artifact
|   |           └── ItemStat
|   └── Source
|       ├── Author
|       ├── Patch
|       └── Revision
|           └── Author
└── User
    └── Identity

Hooks

A subset of APIs are exposed using simple hook credentials. These credentials are coupled to a provider (e.g. travis-ci) and a single repository.

To create a new hook:

zeus hooks add https://github.com/getsentry/zeus.git travis-ci

Using the subpath, you'll be able to access several endpoints:

• {prefix}/builds/{build-external-id}
• {prefix}/builds/{build-external-id}/jobs/{job-external-id}
• {prefix}/builds/{build-external-id}/jobs/{job-external-id}/artifacts

The prefix will be generated for you as part of the a new hook, and is made up of the Hook's GUID and it's signature:

http://example.com/hooks/{hook-id}/{hook-signature}/{path}

Each endpoint takes an external ID, which is used as a unique query parameter. The constraints are coupled to the parent object. For example, to create or patch a build:

POST http://example.com/hooks/{hook-id}/{hook-signature}/builds/abc

This will look for a Build object with the following characteristics:

• provider={Hook.provider}
• external_id=abc
• repository_id={Hook.repository_id}

If a match is found, it will be updated with the given API parameters. If it isn't found, it will be created.