1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
Source: python-subunit2sql
Section: python
Priority: optional
Maintainer: Debian OpenStack <team+openstack@tracker.debian.org>
Uploaders:
Thomas Goirand <zigo@debian.org>,
Build-Depends:
debhelper (>= 10),
dh-python,
openstack-pkg-tools,
python-all,
python-pbr (>= 2.0.0),
python-setuptools,
python3-all,
python3-pbr (>= 2.0.0),
python3-setuptools,
python3-sphinx,
Build-Depends-Indep:
alembic (>= 0.8.10),
python-alembic (>= 0.8.10),
python-coverage,
python-dateutil,
python-fixtures,
python-hacking,
python-mock,
python-oslo.concurrency,
python-oslo.config (>= 1:4.0.0),
python-oslo.db (>= 4.24.0),
python-psycopg2,
python-pymysql,
python-reno,
python-six,
python-sqlalchemy,
python-stestr,
python-stevedore (>= 1.20.0),
python-testresources,
python-testscenarios,
python-testtools,
python3-alembic (>= 0.8.10),
python3-dateutil,
python3-fixtures,
python3-mock,
python3-openstackdocstheme,
python3-oslo.concurrency,
python3-oslo.config (>= 1:4.0.0),
python3-oslo.db (>= 4.24.0),
python3-psycopg2,
python3-pymysql,
python3-six,
python3-sqlalchemy,
python3-stestr,
python3-stevedore (>= 1.20.0),
python3-testresources,
python3-testscenarios,
python3-testtools,
subunit,
Standards-Version: 4.1.1
Vcs-Browser: https://salsa.debian.org/openstack-team/libs/python-subunit2sql
Vcs-Git: https://salsa.debian.org/openstack-team/libs/python-subunit2sql.git
Homepage: https://github.com/openstack-infra/subunit2sql
Package: python-subunit2sql
Architecture: all
Depends:
alembic (>= 0.8.10),
python-alembic (>= 0.8.10),
python-dateutil,
python-oslo.config (>= 1:4.0.0),
python-oslo.db (>= 4.24.0),
python-pbr (>= 2.0.0),
python-six,
python-sqlalchemy,
python-stevedore (>= 1.20.0),
subunit,
${misc:Depends},
${python:Depends},
Suggests:
python-subunit2sql-doc,
Description: subunit file/stream to DB - Python 2.7
subunit2SQL is a tool for storing test results data in a SQL database. Like
it's name implies it was originally designed around converting subunit streams
to data in a SQL database and the packaged utilities assume a subunit stream
as the input format. However, the data model used for the DB does not preclude
using any test result format. Additionally the analysis tooling built on top
of a database is data format agnostic. However if you choose to use a
different result format as an input for the database additional tooling using
the DB API would need to be created to parse a different test result output
format. It's also worth pointing out that subunit has several language library
bindings available. So as a user you could create a small filter to convert a
different format to subunit. Creating a filter should be fairly easy and then
you don't have to worry about writing a tool like :ref:`subunit2sql` to use a
different format.
.
For multiple distributed test runs that are generating subunit output it is
useful to store the results in a unified repository. This is the motivation for
the testrepository project which does a good job for centralizing the results
from multiple test runs.
.
However, imagine something like the OpenStack CI system where the same basic
test suite is normally run several hundreds of times a day. To provide useful
introspection on the data from those runs and to build trends over time the
test results need to be stored in a format that allows for easy querying.
Using a SQL database makes a lot of sense for doing this, which was the
original motivation for the project.
.
At a high level subunit2SQL uses alembic migrations to setup a DB schema that
can then be used by the subunit2sql tool to parse subunit streams and populate
the DB. Then there are tools for interacting with the stored data in the
subunit2sql-graph command as well as the sql2subunit command to create a
subunit stream from data in the database. Additionally, subunit2sql provides a
Python DB API that can be used to query information from the stored data to
build other tooling.
.
This package contains the Python 2.7 module.
Package: python-subunit2sql-doc
Section: doc
Architecture: all
Depends:
${misc:Depends},
${sphinxdoc:Depends},
Description: subunit file/stream to DB - doc
subunit2SQL is a tool for storing test results data in a SQL database. Like
it's name implies it was originally designed around converting subunit streams
to data in a SQL database and the packaged utilities assume a subunit stream
as the input format. However, the data model used for the DB does not preclude
using any test result format. Additionally the analysis tooling built on top
of a database is data format agnostic. However if you choose to use a
different result format as an input for the database additional tooling using
the DB API would need to be created to parse a different test result output
format. It's also worth pointing out that subunit has several language library
bindings available. So as a user you could create a small filter to convert a
different format to subunit. Creating a filter should be fairly easy and then
you don't have to worry about writing a tool like :ref:`subunit2sql` to use a
different format.
.
For multiple distributed test runs that are generating subunit output it is
useful to store the results in a unified repository. This is the motivation for
the testrepository project which does a good job for centralizing the results
from multiple test runs.
.
However, imagine something like the OpenStack CI system where the same basic
test suite is normally run several hundreds of times a day. To provide useful
introspection on the data from those runs and to build trends over time the
test results need to be stored in a format that allows for easy querying.
Using a SQL database makes a lot of sense for doing this, which was the
original motivation for the project.
.
At a high level subunit2SQL uses alembic migrations to setup a DB schema that
can then be used by the subunit2sql tool to parse subunit streams and populate
the DB. Then there are tools for interacting with the stored data in the
subunit2sql-graph command as well as the sql2subunit command to create a
subunit stream from data in the database. Additionally, subunit2sql provides a
Python DB API that can be used to query information from the stored data to
build other tooling.
.
This package contains the documentation.
Package: python3-subunit2sql
Architecture: all
Depends:
alembic (>= 0.8.10),
python3-alembic (>= 0.8.10),
python3-dateutil,
python3-oslo.config (>= 1:4.0.0),
python3-oslo.db (>= 4.24.0),
python3-pbr (>= 2.0.0),
python3-six,
python3-sqlalchemy,
python3-stevedore (>= 1.20.),
subunit,
${misc:Depends},
${python3:Depends},
Suggests:
python-subunit2sql-doc,
Description: subunit file/stream to DB - Python 3.x
subunit2SQL is a tool for storing test results data in a SQL database. Like
it's name implies it was originally designed around converting subunit streams
to data in a SQL database and the packaged utilities assume a subunit stream
as the input format. However, the data model used for the DB does not preclude
using any test result format. Additionally the analysis tooling built on top
of a database is data format agnostic. However if you choose to use a
different result format as an input for the database additional tooling using
the DB API would need to be created to parse a different test result output
format. It's also worth pointing out that subunit has several language library
bindings available. So as a user you could create a small filter to convert a
different format to subunit. Creating a filter should be fairly easy and then
you don't have to worry about writing a tool like :ref:`subunit2sql` to use a
different format.
.
For multiple distributed test runs that are generating subunit output it is
useful to store the results in a unified repository. This is the motivation for
the testrepository project which does a good job for centralizing the results
from multiple test runs.
.
However, imagine something like the OpenStack CI system where the same basic
test suite is normally run several hundreds of times a day. To provide useful
introspection on the data from those runs and to build trends over time the
test results need to be stored in a format that allows for easy querying.
Using a SQL database makes a lot of sense for doing this, which was the
original motivation for the project.
.
At a high level subunit2SQL uses alembic migrations to setup a DB schema that
can then be used by the subunit2sql tool to parse subunit streams and populate
the DB. Then there are tools for interacting with the stored data in the
subunit2sql-graph command as well as the sql2subunit command to create a
subunit stream from data in the database. Additionally, subunit2sql provides a
Python DB API that can be used to query information from the stored data to
build other tooling.
.
This package contains the Python 3.x module.
|
