[AutoQA] #125: initscripts: Choosing the right repo for dependencies
by fedora-badges
#125: initscripts: Choosing the right repo for dependencies
-------------------------+--------------------------------------------------
Reporter: kparal | Owner: jskladan
Type: task | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: initscripts |
-------------------------+--------------------------------------------------
Currently after new Koji build the initscripts test downloads all relevant
binary packages (related to the particular source package) and installs
them. But the RPM dependencies are installed from stable/updates repos,
not from Koji. Also the dependencies parsed out of Makefile are installed
from stable/updates repos.
We have to inquire a little more into this situation. Is it
sufficient/desirable? Or is it desirable to download dependencies from
updates-testing or bleeding edge Koji? May the initscripts test sometimes
fail because of insufficient dependencies are in stable/updates repos?
This also depends on cases when we are going to use initscripts test. If
it will be used with Bodhi hook, it will be probably easier to solve it
than when used with Koji hook.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/125>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 6 months
[AutoQA] #102: post-iso-build hook
by fedora-badges
#102: post-iso-build hook
----------------------+-----------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: watchers | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
We need one (or more) standard locations where new iso images get posted
for testing, and a watcher that can monitor for new iso images and launch
appropriate installation/sanity tests.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/102>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 8 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] #123: rpmguard: check upgrade paths between releases
by fedora-badges
#123: rpmguard: check upgrade paths between releases
----------------------+-----------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: rpmguard |
----------------------+-----------------------------------------------------
(As pointed out by spot on the devel list:
http://lists.fedoraproject.org/pipermail/devel/2010-March/131746.html)
We should be emitting warning/error messages if the new package(s) have a
higher ENVR than the currently-released package(s) in any newer release.
For example, right now a new F11 package should be checked against the
corresponding package(s) in the current F12, branched F13, and rawhide
repos.
This involves a lot of extra repos and metadata, though. It's not a
trivial thing to add.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/123>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 7 months
[AutoQA] #111: depcheck test
by fedora-badges
#111: depcheck test
--------------------+-------------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: autoqa depcheck
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
Write an actual depcheck test. This test should take, as inputs:
* one or more new package builds, and
* the name of a target repository for the new build(s)
The test should examine the PRCO (provides/requires/conflicts/obsoletes)
data for the new package(s) and the PRCO data for the target repository
(and all its parent repos).
The test should fail if the new builds would cause missing/broken
dependencies or unresolveable conflicts in the target repo(s).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/111>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months
[AutoQA] #118: New test proposal: Python debugability
by fedora-badges
#118: New test proposal: Python debugability
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
From Adam Williamson:
I've cut some of the context, but
basically David wants to write a test case for checking whether Python
debugging is possible as intended, and I asked exactly how he wanted it
to be used.
{{{
On Tue, 2010-01-26 at 15:30 -0500, David Malcolm wrote:
> > > Can I request a test case to cover debuggability of the Python
> runtime
> > > please (both in Fedora and in RHEL).
> > >
> > > This is in relation to:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=556975
> > > https://bugzilla.redhat.com/show_bug.cgi?id=558977
> > > https://bugzilla.redhat.com/show_bug.cgi?id=557772
> > >
> > > as there seem to be gcc and gdb issues, which are conspiring to
> make
> > > python impossible to debug.
> > >
> > >
> > > The requirement is: within "gdb python", I must be able to select
> a
> > > PyEval_EvalFrameEx frame, and have the following work:
> > > (gdb) print co
> > > (gdb) print f
> > >
> > > rather that have <variable optimized out>
> > >
> > > so that I can do this:
> > > (gdb) print (char*)(((PyStringObject*)co->co_name)->ob_sval)
> > > to get the function name
> > >
> > > (gdb) print (char*)(((PyStringObject*)co->co_filename)->ob_sval)
> > > to get the source filename
> > >
> > > and
> > >
> > > (gdb) print f->f_lineno
> > > to get the approximate source line number.
> > >
> > > If the above isn't working, it becomes extremely hard to
> meaningfully
> > > debug any issues that arise inside Python.
> This is probably scriptable, and a good candidate for AutoQA and foe
> RHTS.
>
}}}
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/118>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months
[AutoQA] #107: writing a python test (modeled similarly to install.py)
by fedora-badges
#107: writing a python test (modeled similarly to install.py)
-------------------+--------------------------------------------------------
Reporter: liam | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: tests | Version: 1.0
Keywords: |
-------------------+--------------------------------------------------------
write a python test (modeled similarly to install.py) that takes as input:
* a URL to a kickstart file (URL can be local (e.g. file://) or
remote (e.g. http://, ftp://, nfs:// ...) ... but start with easy case
first.
* a URL for the install media (again, keep this simple for now and
assume file:///var/lib/libvirt/images/Fedora-12-x86_64-DVD.iso)
* a URL to a configuration file that describes the environment -
again, perhaps optional for now. But eventually we'll need
something that tells the test to create a guest with 4 NICs vs 1
NIC, 3 SCSI drives etc... Don't worry about being fancy at
first ... just take the defaults. This is just where I might
see it headed in 6+ months. Copy from the kvm autotest project
if you like.
At beginning, we focus on the basics and something that gets things far
enough along so we can review, adjust and repeat.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/107>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 9 months
[AutoQA] #115: Update post-tree-compose to recognize new stage2 URL
by fedora-badges
#115: Update post-tree-compose to recognize new stage2 URL
-------------------------+--------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Automate installation test plan
Component: watchers | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
During Fedora 13, release engineering will provide schedule drops of
rawhide for automated testing against rats_install. The provided data
will include a compose tree (without packages). For proper automated
testing of these images, post-tree-compose will need to monitor a new URL
for testing (likely candidate is
http://alt.fedoraproject.org/pub/alt/stage/rawhide-testing).
In addition, rats_install will need to support installing with stage2 and
the package repo in different locations. That will be tracked in another
ticket.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/115>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 9 months
[AutoQA] #129: create auto install test script which maps 1x1 to the install method.
by fedora-badges
#129: create auto install test script which maps 1x1 to the install method.
-------------------+--------------------------------------------------------
Reporter: liam | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Version: 1.0
Keywords: |
-------------------+--------------------------------------------------------
Each install method should have an install test script, For example:
* Single ISO install - dvd_install.py
* Multi ISO install - cd_install.py
* Hard Drive ISO install - hdiso_install.py
* NFS install - nfs_install.py
* NFS ISO install - nfsiso_install.py
* HTTP/FTP install - url_install.py <-- similar to
rats_install.py now
we need to create these scripts, but each of the script should share code
as much as possible.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/129>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 9 months
[AutoQA] #109: post-bodhi-update watcher
by fedora-badges
#109: post-bodhi-update watcher
----------------------+-----------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: autoqa depcheck
Component: watchers | Version: 1.0
Keywords: |
----------------------+-----------------------------------------------------
the post-bodhi-update hook (see ticket #87) will require a post-bodhi-
update watcher. This should use the bodhi API to get info about newly-
created/changed updates and fire tests.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/109>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 10 months