Gump generates data about the state of interactions of OSS projects, this data is the real work product of Gump (not the output artifacts stored in it's repositories).
Gump interacts with DBM databases (except on M$ where Python does not support them) and MySQL databases.
Gump stores simple 'running counter' type statistics for each GumpEntity. These records have the following form:
- Prereqs (not done due to pre-requisite failures)
- datetime of first (success)
- datetime of last (success) .. i.e. latest.
- current state (e.g. success)
- previous state
- datetime of start of this state
- sequence (in runs) in this state
If no MySQL database is available Gump uses DBM for these
If a MySQL database is available Gump uses it with the following GumpDatabase/Schema.
On a per GumpEntity basis Gump stores run information:
- The run GUID
The GumpEntity name
these two (above) constitute the primary key
- The state
- The reason code
The cause (which other GumpEntity caised grief)
- Start datetime
- End datetime
- Number of outputs
- Total size of outputs
- Numbers (including totals) of dependees/dependencies