[AutoQA] #153: rpmguard: Separate checks into individual python files
by fedora-badges
#153: rpmguard: Separate checks into individual python files
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: rpmguard |
-------------------------+--------------------------------------------------
It would be great to have individual checks in rpmguard available as
separate files, very similarly to what rpmlint or yum (-plugins) use. It
would allow easy enabling/disabling of specific check, it would allow easy
contribution of a new check.
More ideas and information here: https://fedorahosted.org/pipermail
/autoqa-devel/2010-May/000496.html
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/153>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 5 months
[AutoQA] #150: "artificial ignorance": suppress errors and warnings that aren't important
by fedora-badges
#150: "artificial ignorance": suppress errors and warnings that aren't important
-------------------------+--------------------------------------------------
Reporter: dmalcolm | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Package Sanity Tests
Component: tests | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
There are some interesting ideas in here about suppressing a logfile to
show up the information that's truly important:
http://www.ranum.com/security/computer_security/papers/ai/index.html
I think that the rpmlint test needs to have a set of filters, and should
suppress output matching certain patterns. For example
https://fedorahosted.org/pipermail/autoqa-results/2010-April/013903.html
shows:
{{{
gnome-python2-gnome.i686: W: spelling-error Summary(en_US) libgnome -> lib
gnome, lib-gnome, cognomen
}}}
i.e. it's complaining about a reference to "libgnome" within gnome-
python2-gnome, which is clearly a false-positive.
For this case we might have a python filtering process that says something
like this (caveat: untested):
{{{
patterns = [
": W: spelling-error \S+ libgnome .*",
]
def should_ignore(line):
for pat in patterns
# May want to precompile the patterns:
m = re.match(pat, line)
if m:
return True
# No match:
return False
for line in rpmlint_output
if not should_ignore(line):
print(line)
}}}
and then gradually grow patterns. The idea is to make it nice and
lightweight, and Fedora QA can then easily take ownership of the
suppresssions, without having to get patches into rpmlint.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/150>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 5 months
[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