[AutoQA] #251: Move autotest applications into /usr/*bin
by fedora-badges
#251: Move autotest applications into /usr/*bin
-----------------------+----------------------------------------------------
Reporter: jlaska | Owner:
Type: task | Status: new
Priority: minor | Milestone: Packaging, Review, & Deployment
Component: packaging | Keywords:
-----------------------+----------------------------------------------------
The autotest package should supply binaries in /usr/bin/ ... so we can
rely on PATH and not have to call autotest with the full-path
(/usr/share/autotest/client/bin/autotest) when scheduling jobs in
'/usr/bin/autoqa'.
Alternatively, the autotest package could drop a script that updates PATH
appropriately into /etc/profile.d/autotest. But yuck.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/251>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 6 months
[AutoQA] #157: conflicts: requested arch not respected
by fedora-badges
#157: conflicts: requested arch not respected
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
This is a bug in the potential_conflict.py script in tests/conflicts/.
Usage suggests using --arch options for specifying requested architecture
to be tested. But if you look at the attached log, the first and second
output match (that's correct), but the third doesn't match, even though it
should. Everything was tested on x86_64 machine.
Also from the usage line it is not clear whether --arch is related only to
particular yum repository selection (replacing $basearch keyword), or
whether it also relates to packages built for one architecture but being
in different repo (e.g. i686 packages are very often in x86_64 repo).
I have looked into the source code of the script and it seems that the
--arch option is not used at all, just printed out in the usage help??
Seth, you're listed as script author. Any comments on that? Thanks.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/157>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #329: implement RPM checksum verification
by fedora-badges
#329: implement RPM checksum verification
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Finger Food
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently this method is in autoqa.util module:
{{{
261 def valid_rpm(rpm_file):
262 '''Check that RPM file is valid.
263 Note: This currently only extracts RPM header and presumes the
file is
264 OK if that succeeds. Full RPM hashsum check would be nice to
have
265 implemented too (FIXME).
266 @param rpm_file RPM file path
267 @return True if file seems OK or False if there is some
problem (file
268 can't be read, RPM header is corrupt)
269 '''
...
}}}
We would like to have full RPM checksum verification, not just reading the
header and saying that it's OK. Find out how to do it and change the
method accordingly. It would be nice to have a method argument to enable
full checksum verification/fall back to original header verification,
because it can be performance intensive operation and it may not be
suitable for all our use cases).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/329>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
11 years, 8 months
[AutoQA] #206: Update bodhi to enforce Package Update Acceptance policy
by fedora-badges
#206: Update bodhi to enforce Package Update Acceptance policy
----------------------------+-----------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component: infrastructure | Version: 1.0
Keywords: |
----------------------------+-----------------------------------------------
In order to enforce the Package Update Acceptance Test Plan, Bodhi will
need be modified to reject the push of any package that fails acceptance
testing.
The acceptance tests may need to send status/data to bodhi in order for it
to make decisions about policy (see e.g. ticket #205). Later bodhi might
just get data from resultdb (see that milestone for details).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/206>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years
[AutoQA] #252: Provide all autotest client combinations that we need
by fedora-badges
#252: Provide all autotest client combinations that we need
------------------------+---------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: 0.5.0
Component: production | Keywords:
------------------------+---------------------------------------------------
Currently our production server at http://autoqa.fedoraproject.org/ has 6
autotest clients assigned, all bare metals with Fedora 13 installed, with
mixed architectures. But we need more.
According to https://fedoraproject.org/wiki/Managing_autotest_labels we
have two architecture labels, two fedora release labels (the two currently
supported Fedora releases, I would omit Rawhide for now) and two virt
labels (virtual machine or bare metal). We need machines for every
combination of those labels (that is 8 IICC - if I count correctly). And
we would like to see a bit more 64bit machines, because we use them for
noarch tests.
Currently the only test that really requires all those combinations is
initscripts test. But there will be more in the future. It is quite some
farm, but it seems we'll have to build it.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/252>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
[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, 1 month
[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, 1 month