This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description

Job Control

Job scheduling and tracking library.

Provides a base interface for scheduling, running, tracking and retrieving results for “jobs”.

Each job definition is simply any Python callable, along with arguments to be passed to it.

The tracking include storing: - the function return value - any exception raised - log messages produced during task execution - optionally a “progress”, if the task supports it

The status storage is completely decoupled from the main application.

The project “core” currently includes two storage implementations:

  • MemoryStorage – keeps all data in memory, useful for development / testing.
  • PostgreSQLStorage – keeps all data in a PostgreSQL database, meant for production use.

Project status

Travis CI build status

Branch Status
master
develop

Source code

Source is hosted on GitHub: https://github.com/rshk/jobcontrol/

And can be cloned with:

git clone https://github.com/rshk/jobcontrol.git

Python Package Index

The project can be found on PyPI here: https://pypi.python.org/pypi/jobcontrol

Project documentation

Documentation is hosted on GitHub pages: (coming soon!) http://rshk.github.io/jobcontrol/

Concepts

  • Each job is defined as a Python function to be run, with arguments and keywords.
  • Each job can depend on other jobs; the dependency sistem ensures all dependencies are built before running a given job, and that depending jobs are rebuilt when a “higher-level” one is built.

Example:

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│         │   │         │   │         │   │         │
│  Job A  │ → │  Job B  │ → │  Job C  │ → │  Job D  │
│         │   │         │   │         │   │         │
└─────────┘   └─────────┘   └─────────┘   └─────────┘

When running the task C, a build of B will be required; this in turn requires a build of A. If build_deps=True was specified, a build of C and B will be triggered. Otherwise, the build will terminate with a “dependencies not met” error.

After a successful build of C, D is not outdated. If build_depending=True was specified, a build of D will be triggered.

Other example: Job #2 depends on Job #2:

Job #1

Build Succ? Time Skip?
1 TRUE 1 FALSE
2 FALSE 3 FALSE
3 TRUE 4 TRUE
4 TRUE 5 FALSE

Job #2

Build Succ? Time Skip?
1 TRUE 2 FALSE
No rebuild needed.
No rebuild needed.
2 TRUE 6 FALSE

Changelog

v0.1a

  • Support definition of jobs, with: function, args, kwargs, dependencies
  • Support tracking of job runs, with start/end date, started/finished/success state and return value
  • Support for storing logs from job runs
  • Memory-backed storage (for state)
  • PostgreSQL-backed storage (for state)
Release History

Release History

0.1a

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting