[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] #237: Crontab file no longer installed
by fedora-badges
#237: Crontab file no longer installed
-----------------------+----------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Outdated documentation
Component: docs/wiki | Version: 1.0
Keywords: |
-----------------------+----------------------------------------------------
Crontab file no longer installed - We no longer install crontab file into
/etc/cron.d/autoqa. Therefore there is no longer need to comment out this
file on clients. Also, this file must be created on servers (we install a
template as a documentation file).
We must fix the docs.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/237>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 5 months
[AutoQA] #236: Self variables
by fedora-badges
#236: Self variables
-----------------------+----------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Outdated documentation
Component: docs/wiki | Version: 1.0
Keywords: |
-----------------------+----------------------------------------------------
Self variables may be set any time - We have recommended to set
self.result and similar variables only at the end of the test (because of
our old exception handling). It is no longer the case. Self.* variables
may be set any time. Also, commit 8e4e894acade8139a3f4ffd9351fa53b3f0e0b46
allowed self.outputs and self.highlights to be lists of strings.
We must fix the docs.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/236>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 5 months
[AutoQA] #234: output.log
by fedora-badges
#234: output.log
-----------------------+----------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Outdated documentation
Component: docs/wiki | Version: 1.0
Keywords: |
-----------------------+----------------------------------------------------
Commit 03ca1e86ceed16dd58ae3ef606362980012894d0 ensured all email output
is stored in output.log. We should mention it in the docs.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/234>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 5 months
Re: Update to autoqa-0.4.3-1
by Kamil Paral
----- "Kamil Paral" <kparal(a)redhat.com> wrote:
> Thanks, James, patches look completely fine. My quick smoke test
> succeeded.
>
> Let's deploy! :)
One more thing. Since autoqa 0.4.3 is now out, we should fix the
outdated documentation:
https://fedorahosted.org/autoqa/query?status=new&status=assigned&status=r...
So if anyone is interested (all of you, right?:)) please grab a ticket
and fix the wiki, thanks.
For the next release I think I'll discard "Outdated documentation"
milestone and propose a different workflow:
1. If possible, fix documentation right after the patch is pushed
to master :o)
2. If you don't want to do 1), then instead of closing the corresponding
ticket, just change the component to "documentation" and leave it
open. And make sure the milestone is set to the next autoqa release
(currently 0.4.4). That way we will see what documentation we need to
fix before releasing a new version.
3. If there is no ticket for your patch (and it requires documentation
changes), just create a new ticket, provide a description with your
patch checksum, and assign to "documentation" component and nearest
release milestone.
This way we should be able to track outdated documentation nicely and
it doesn't require any more work than with current approach. The bonus
is that those tickets will block our next release, so that we don't
forget about them.
13 years, 5 months
duplicate comments in Bodhi
by Kamil Paral
This is an interesting problem. We want to post comments from AutoQA
into Bodhi. But some of our tests are designed in such a way that they
test a particular package several (dozen) times. For example depcheck
will test all packages in -updates-pending every time this tag is updated
(new package is added/removed).
If some package fails depcheck, we probably don't want to add 10 comments
to its Bodhi page saying "depcheck failed" every single day.
So we devised a solution where we won't post duplicate comments. If
the first comment says "depcheck fails", we won't post any new comment
until it says something else.
But that has a catch - we also want to add a URL to the full results
of the test. If we don't post duplicate comments, the maintainer will
see just the original URL. But the reason of the failure might have
changed. How do we tell the maintainer what's wrong when we don't post
updated URL?
One silly idea I've come up with is that we will post duplicate comments,
but only once in a few days. For example we will post "depcheck failed
(URL)" again only after at least two days from the previous "depcheck
failed (URL)".
Ideas?
13 years, 6 months
