[AutoQA] #138: ResultsDB: media wiki as a storage for metadata about tests
by fedora-badges
#138: ResultsDB: media wiki as a storage for metadata about tests
----------------------------+-----------------------------------------------
Reporter: jskladan | Owner:
Type: task | Status: new
Priority: major | Milestone: Resultdb
Component: infrastructure | Version: 1.0
Keywords: |
----------------------------+-----------------------------------------------
Once #135 #136 and #137 are finished, we should create a provider/middle
man (probably a library) which will allow us to get information about the
respective test and use it for test execution/storing results/displaying
results via frontends...
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/138>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 6 months
[AutoQA] #137: ResultsDB: propose structure for storing metadata about tests on wiki
by fedora-badges
#137: ResultsDB: propose structure for storing metadata about tests on wiki
-----------------------+----------------------------------------------------
Reporter: jskladan | Owner:
Type: task | Status: new
Priority: major | Milestone: Resultdb
Component: docs/wiki | Version: 1.0
Keywords: |
-----------------------+----------------------------------------------------
We want to use mediawiki as a storage for tests metadata. We should agree
on the fields we want to store (e.g. test owner, destructive/non-
destructive, average time to complete test etc.) and the format we'll use
to store it (probably JSON though).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/137>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 6 months
[AutoQA] #134: ResultsDB: create resultsdb prototype
by fedora-badges
#134: ResultsDB: create resultsdb prototype
----------------------+-----------------------------------------------------
Reporter: jskladan | Owner:
Type: task | Status: new
Priority: major | Milestone: Resultdb
Component: tests | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
Create prototype of database and software which will implement dbSchema
from #133 and API from #131
This prototype should also include some test suite, which will be used to
determine, if all the functionality is OK.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/134>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 6 months
[AutoQA] #202: testcases for depcheck
by fedora-badges
#202: testcases for depcheck
--------------------+-------------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan - depcheck
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
To be sure that depcheck is operating as expected, we should have a
library of test cases for it.
These test cases could take the form of a set (or sets) of trivial RPMs
that illustrate various possible dependency problems - or a script that
generates RPMs like that.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/202>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 7 months
[AutoQA] #123: rpmguard: check upgrade paths between releases
by fedora-badges
#123: rpmguard: check upgrade paths between releases
----------------------+-----------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: rpmguard |
----------------------+-----------------------------------------------------
(As pointed out by spot on the devel list:
http://lists.fedoraproject.org/pipermail/devel/2010-March/131746.html)
We should be emitting warning/error messages if the new package(s) have a
higher ENVR than the currently-released package(s) in any newer release.
For example, right now a new F11 package should be checked against the
corresponding package(s) in the current F12, branched F13, and rawhide
repos.
This involves a lot of extra repos and metadata, though. It's not a
trivial thing to add.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/123>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months
[AutoQA] #111: depcheck test
by fedora-badges
#111: depcheck test
--------------------+-------------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: autoqa depcheck
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
Write an actual depcheck test. This test should take, as inputs:
* one or more new package builds, and
* the name of a target repository for the new build(s)
The test should examine the PRCO (provides/requires/conflicts/obsoletes)
data for the new package(s) and the PRCO data for the target repository
(and all its parent repos).
The test should fail if the new builds would cause missing/broken
dependencies or unresolveable conflicts in the target repo(s).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/111>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months
[AutoQA] #199: Standardize (some) AutoQA test args
by fedora-badges
#199: Standardize (some) AutoQA test args
-----------------------+----------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Multi-hook tests
Component: docs/wiki | Version: 1.0
Keywords: |
-----------------------+----------------------------------------------------
The various hooks that AutoQA provides each have different test args. Some
of these arguments are similar or identical across hooks - for example,
'config' applies to all hooks. Each hook also has an argument that
represents the name of the thing to be tested, but this varies from hook
to hook - it's a reponame for post-repo-update, treename for post-tree-
compose, etc.
We should document and standardize these argument names so that it's
easier to write tests that will run for multiple hooks. For example, maybe
all hooks should use 'name' to represent the name of the thing being
tested.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/199>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months