[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges
#255: Use Config class to simplify access to configuration options
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: core | Keywords:
--------------------+-------------------------------------------------------
Currently all our libraries and tests use ConfigParser and parse our
configuration files (autoqa.conf, fas.conf, etc) directly. That is not
ideal, it involves many lines of code, converting to correct variable
types (int, bool), handling default values, and so on.
We should create a Python class Config, which is initialized once in the
beginning, and then can be access globally and easily from any other
module. It will handle default values and type conversion centrally in one
place. Also access will be much easier.
PS: We already have autoqa.config module. Maybe we just don't use it?
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/255>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #350: Add support for using file proxy
by fedora-badges
#350: Add support for using file proxy
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Future tasks
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently we allow to cache downloaded RPMs with allow_pkg_cache in
autoqa.conf. That uses our own code in util.py:download().
Tim was talking about using file proxy and it now seems to me as a far
better approach. It can cache more files (like yum metadata, ISO files,
etc). The proxy can run on the same computer or on some local-network
computer. Several computers can share the same proxy. We don't have to
care about storing the files and cleaning up the directories. It means
less code. It's transparent for us.
The task now is to play with some proxy, try whether it works, implement
some support for AutoQA (if required), and document the process of setting
it up (probably in [https://fedoraproject.org/wiki/AutoQA_Development
here]).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/350>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #394: All tests must have their maintainer defined
by fedora-badges
#394: All tests must have their maintainer defined
---------------------+-------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone: Finger Food
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+-------------------------
Occasionally we are running into issues with tests for which we are not
sure who to ask help with. Every test should have its "maintainer"
defined. The maintainer is a person who to ask about implementation
details or who to harass about bugs.
Currently the autotest's control file contains AUTHOR="..." line. Maybe we
should use that for maintainer definition (even though it might be a
little misleading). Or maybe we should define and use a MAINTAINER="..."
variable.
The task is:
1. Find the best way where to define each test's maintainer
(AUTHOR/MAINTAINER inside control file, etc).
2. Decide whether we need to check its existence.
3. Find maintainers for every test present inside AutoQA and fill it in
inside the source code.
4. Amend the documentation.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/394>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #390: update rats_install
by fedora-badges
#390: update rats_install
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner: hongqing
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: core | Keywords:
----------------------+-----------------------------------------------------
rats_install does not work after F14. after investigating in it, The
following things should be updated:[[BR]]
1. install.img is compressed into initrd.img, remove the exist check
2. initrd.img is compressed as XZ compressed file instead of gzip
compressed file, gzip in python has to be replaced
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/390>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges
#338: AutoQATest.version - is it needed?
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: trivial | Milestone: Finger Food
Component: tests | Keywords:
-------------------------+--------------------------------------------------
In all our tests we have code like this:
{{{
class rpmlint(AutoQATest):
version = 1 # increment if setup() changes
}}}
The question is - is the ''version'' attribute needed and being used at
all? I have never seen any difference in behavior, the setup() phase is
run every time.
We should have look at autotest documentation or source code whether this
is being used and when. If we don't need it, let's remove it from all our
tests and templates (the less code the better).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/338>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #194: Incorporate automated anaconda storage suite
by fedora-badges
#194: Incorporate automated anaconda storage suite
--------------------+-------------------------------------------------------
Reporter: jlaska | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
Chris Lumens has developed a virt-based test suite to automate different
disk/storage install scenarios. I've discussed this briefly with Chris,
but I'd be interested in seeing his test suite incorporated within autoqa
and run on a regular interval (perhaps along-side Liam's install tests).
The tests are currently available at http://clumens.fedorapeople.org
/anaconda-storage-test/
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/194>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months
[AutoQA] #398: depcheck is sometimes scheduled as noarch
by fedora-badges
#398: depcheck is sometimes scheduled as noarch
---------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Hot issues
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+------------------------
Generally the koji-bodhi watcher schedules both i386 and x86_64
architectures of depcheck:
{{{
# autoqa post-bodhi-update-batch --targettag f16-updates --arch x86_64
--arch i386 openssl-1.0.0f-1.fc16 --dryrun
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -f /tmp/autoqa-control.le3exd post-bodhi-update-
batch:upgradepath.noarch
Keeping /tmp/autoqa-control.le3exd at user request
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*x86_64 -d fc16 -f /tmp/autoqa-control.FscGAS post-bodhi-update-
batch:depcheck.x86_64
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*i386 -d fc16 -f /tmp/autoqa-control._QiAVV post-bodhi-update-
batch:depcheck.i386
Keeping /tmp/autoqa-control._QiAVV at user request
}}}
But sometimes it might happen that the only new updated package is a
noarch package. Then the watcher "optimized" the arguments by leaving out
"--arch i386" and "--arch x86_64", therefore using the argument "--arch
noarch" that is implied by default:
{{{
# autoqa post-bodhi-update-batch --targettag f16-updates
rpmlint-1.0.0f-1.fc16 --dryrun
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -f /tmp/autoqa-control.mlUFRG post-bodhi-update-
batch:upgradepath.noarch
Keeping /tmp/autoqa-control.mlUFRG at user request
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -d fc16 -f /tmp/autoqa-control.zpet6Z post-bodhi-update-
batch:depcheck.noarch
Keeping /tmp/autoqa-control.zpet6Z at user request
}}}
Unfortunately this doesn't work for depcheck. Depcheck is then scheduled
as noarch test, therefore run on arbitrary machine, and the test result is
also reported as "depcheck on noarch" into Bodhi.
We need to study this problem in detail and decide whether we should
change the watcher (schedule both architectures?) or implement new
features in the scheduling process (create a way for depcheck's
control.autoqa to insist on running both architectures every time?).
This is not super-critical because even though we provide some invalid
comments in Bodhi, we will probably schedule correct depcheck tests in the
following runs and test the package again. But it is unpleasant
nevertheless.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/398>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 2 months