[AutoQA] #357: Remove pre-Python 2.5 workarounds
by fedora-badges
#357: Remove pre-Python 2.5 workarounds
---------------------+------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: trivial | Milestone: Finger Food
Component: core | Keywords:
---------------------+------------------------------------------------------
We finally have RHEL6 on production server. Go through the source code and
remove pre-Python 2.5 workarounds we had there (most notable workarounds
for try-catch-except blocks).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/357>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
Proposed Configuration Changes for Autotest
by Tim Flink
As part of getting a URL shortener to work with autotest, I have been
working to refactor the apache config that ships with autotest.
The default configuration overwrites the DocumentRoot directive in a
VirtualHost on the autotest server. This means that any other
applications using apache have to be installed
in /usr/share/autotest/apache/www if they use the same hostname on the
autotest server.
So our options become:
1. Install any URL shortener inside the autotest installation
2. Create a new Virtual Host with a different hostname
3. Change the autotest apache config to not change DocumentRoot
4. Don't use the autotest server for the URL shortener
I spoke with Lucas on IRC and he wasn't aware of a reason to be
changing the DocumentRoot for Autotest and would be interested in a
patch that made the configuration work without changing apache so much.
So far as I can tell, nothing uses the modified DocumentRoot by
default. There may be some autotest users that use it for something
(Lucas said that his system uses it for the favicon)
I've written a new configuration file for apache [1] that I think is
mostly equivalent to the current config (the config to change / to the
autotest www root is commented out) but would allow us to install a url
shortener on the autotest server without using another VirtualHost or
the autotest www DocumentRoot.
I'm going to test this new configuration more over the next couple of
days to make sure that it doesn't change any autotest behavior before I
submit it as a patch to autotest. If anyone else feels like testing it,
feel free :)
Tim
[1] http://tflink.fedorapeople.org/autoqa/autotest/autotest.conf
12 years, 9 months
[AutoQA] #360: attach cdrom to guest
by fedora-badges
#360: attach cdrom to guest
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner:
Type: task | Status: new
Priority: minor | Milestone: Automate installation test plan
Component: autotest | Keywords:
----------------------+-----------------------------------------------------
During upgrade, if the previous release is installed from http or ftp with
virt-install, then there is no cdrom device, if we want the guest to be
upgraded from cdrom, cdrom has to be attached first. the current libvirt
version 0.8.* does not support this, but the later release 0.9.* will
support it. Here just open a ticket to wait for the libvirt update.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/360>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
[AutoQA] #104: virtguest.py: accept iso image(s) as install location
by fedora-badges
#104: virtguest.py: accept iso image(s) as install location
--------------------+-------------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
allow {{{VirtGuest.create()}}} to use an iso image (or images) for its
{{{location}}} arg, and automatically choose the appropriate {{{--location
URL}}} or {{{--cdrom IMAGE}}} flag.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/104>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
[AutoQA] #351: Pretty log - filter out the 'ACCEPTED line
by fedora-badges
#351: Pretty log - filter out the 'ACCEPTED line
-------------------------+--------------------------------------------------
Reporter: jskladan | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: 0.6.0
Component: core | Keywords:
-------------------------+--------------------------------------------------
pingou on IRC was a bit 'distracted' by the 'ACEEPTED' line in pretty
logs, and I belive it can be filtered out really simply. Also, the line
does not provide any unique information.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/351>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
Depcheck results for EPEL updates
by James Laska
Greetings gang,
During the EPEL meeting today, Kevin Fenzi asked whether it was possible
for autoqa to run for EPEL updates. Since EPEL uses many of the same
processes and infrastructure used for Fedora builds, I'm wondering how
difficult this would be.
I'm guessing we would need test clients with labels 'el5' and 'el6'
available to accept jobs [1]. Some additional repo targets would be
needed in repoinfo.conf. We'd probably run into python-2.4-isms when
running tests on el5. Kevin also mentioned, that the upgradepath test
might not apply. I'm sure plenty additional changes would be needed.
Has anyone tried this yet?
Thanks,
James
[1] https://fedoraproject.org/wiki/Managing_autotest_labels
12 years, 9 months
[AutoQA] #358: depcheck: previously accepted might not be working correctly
by fedora-badges
#358: depcheck: previously accepted might not be working correctly
----------------------+-----------------------------------------------------
Reporter: jskladan | Owner:
Type: defect | Status: new
Priority: major | Milestone: Depcheck
Component: tests | Keywords:
----------------------+-----------------------------------------------------
While checking up on libreport/abrt depcheck issues, I found weird
depcheck behavior
https://admin.fedoraproject.org/updates/abrt-2.0.3-1.fc15?_csrf_token=14a...
2011-06-21 14:14:52 - AutoQA: depcheck test FAILED on x86_64.
2011-06-21 18:13:05 - AutoQA: depcheck test PASSED on i386
...
2011-06-23 01:13:24 - AutoQA: depcheck test FAILED on i386
2011-06-23 01:16:04 - AutoQA: depcheck test FAILED on x86_64
...
2011-06-23 14:43:52 - AutoQA: depcheck test PASSED on i386
The weird thing (at leasi for me) is that abrt passeed depcheck on i386
(2011-06-21), but still was rescheduled on 2011-06-23 and failed the test.
I thought that if a certain package passes the depcheck test, then we
handle it as 'previously accepted' hence not really testing it any more.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/358>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 9 months
autoqa-0.5.1-1 moved into -testing repository
by James Laska
Greetings gang,
I just built and updated the autoqa -testing repositories with revision release autoqa-0.5.1-1. I'm holding off on deploying this update until Monday. The changes included are listed below (the first 3 being things most people would see).
* Fix for #346 - keep comments from being mangled before posting to bodhi (tflink)
* Updated Makefile targets for improved package builds/updates (jlaska)
* koji-bodhi - Fix failure to acquire lock when cachedir is missing (jlaska)
* compose_tree - Support for multiple packages using either -p or -x. Improve handling of result files. (jlaska)
* git-post-receive - Update wsgi configuration (jlaska)
I attempted to follow the process outlined at https://fedoraproject.org/wiki/AutoQA_Release_Process. Unfortunately, I mistakenly committed all changes to 'master' first, then cherry-picked into release-0.5. I'm trying to think of a way to make sure the autoqa.spec in 'master' is always a superset of anything in the previously released branches. Until we're autogenerating the autoqa.spec, I'm not sure of a clean way to do this.
Thanks,
James
12 years, 9 months
