[AutoQA] #355: Determine Use Cases for Functional Self Tests
by fedora-badges
#355: Determine Use Cases for Functional Self Tests
---------------------------+------------------------------------------------
Reporter: tflink | Owner:
Type: task | Status: new
Priority: minor | Milestone: 0.6.0
Component: documentation | Keywords:
---------------------------+------------------------------------------------
== Description ==
In order to [ticket:352 create functional test cases] and [ticket:353
create mockups for fedora services], we need to have some idea of the use
cases that we would want to test for.
Once this information is gathered, we can start creating the tools that we
need for better self testing in AutoQA.
== Questions to answer ==
NOTE: please add to this list if anything is missing.
* What are we looking to test
* Tests (depcheck, upgradepath etc.)
* Situations (broken deps, not breaking upgrade path etc.)
* What do we need in order to test it
* RPM details
* Repo contents
* Expected Results
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/355>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #345: Implement file locks for all watchers
by fedora-badges
#345: Implement file locks for all watchers
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Finger Food
Component: watchers | Keywords:
-------------------------+--------------------------------------------------
In ticket #342 we implemented file lock for koji-bodhi watcher so that it
is not run concurrently in multiple instances. Implement the same for all
the remaining watchers.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/345>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #368: reconstructe Fedora install test automation framework
by fedora-badges
#368: reconstructe Fedora install test automation framework
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner: hongqing
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: autotest | Keywords:
----------------------+-----------------------------------------------------
A new framework should be constructed to mapping the test cases and
kickstart files, and it also should be easy for the users to contribute.
A big idea is that one text file will be used to map the test case names
and kickstart files, and the kickstart files will be keeped in a
directory, during test, the test will iterate all the kickstart in the
directory. Users can create new kickstart files in the directory and write
the relationship between test case and kickstart in the text file, of
course, they can also pass it by arguments instead of doing this.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/368>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
Mocking Fedora Infrastructure for Fun and for Profit!
by Tim Flink
OK, I finished an initial version of the mock fedora infrastructure
application that I've been working on and the code is up on github.
- https://github.com/tflink/mock_fedorainfra
At the moment, it is capable of proxying bodhi queries and using local
comments instead of the ones from production Bodhi. This means that you
can run a development instance of AutoQA with comments enabled without
having to worry about disrupting production. It also means that you can
re-run jobs multiple times by deleting comments from the html interface.
Since this will be useful for development as well (ability to rerun
jobs at will instead of praying you time it right so that it runs before
production), I have documentation for how to deploy as either a WSGI
app or using the built-in development server:
- http://tflink.github.com/mock_fedorainfra/
The code is still pretty rough but I'm planning to improve it as time
goes on and features are added. If you have problems, please let me
know.
Tim
12 years, 5 months
[AutoQA] #182: Write virt management script
by fedora-badges
#182: Write virt management script
----------------------------+-----------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Virtualization
Component: infrastructure | Version: 1.0
Keywords: |
----------------------------+-----------------------------------------------
We must write a virt management script that will be able to the basic
tasks for us:
* query for available virt systems that we can use
* switch between "real" disk and a disk snapshot for a virt system
* revert a disk snapshot for a virt system
* perform some command in a virt system - e.g. "yum update" for keeping
it periodically up-to-date
* install/reinstall a virt-system for us with specified distro
* (some more to come?)
We may want to use some pre-defined names syntax to recognize what virt
systems do we have. For example:
{{{
/dev/vg_autoqa/F12_i686_1
/dev/vg_autoqa/F12_i686_1-snap
}}}
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/182>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #254: Trasnfer autoqa library to autotest clients
by fedora-badges
#254: Trasnfer autoqa library to autotest clients
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: autotest | Keywords:
-------------------------+--------------------------------------------------
Currently autotest clients do not require autotest package installed,
autotest server transfers all necessary files over rsync. But autotest
clients require autoqa installed (because of our autoqa libraries), which
in turn requires autotest.
This creates quite a lot of confusion where to edit which files when
testing new stuff. It would be much easier if we somehow transferred also
the autoqa library together with autotest files. Can we bend autotest a
little to rsync also our library to the client? Or, can we use similar
approach as copying the config files to the test directory also with
autoqa library? It would be great.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/254>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 5 months
[AutoQA] #196: Log failed job scheduling
by fedora-badges
#196: Log failed job scheduling
-------------------------+--------------------------------------------------
Reporter: kparal | Owner: kparal
Type: enhancement | Status: new
Priority: major | Milestone:
Component: harness | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Currently when we schedule a job and it fails, we just print it out and
forget about it:
{{{
retval = schedule_job(control, email=email, name=testname,
required_arch=arch, dryrun=opts.dryrun,
labels=aq_labels)
if retval != 0:
print "ERROR: failed to schedule job %s" % testname
}}}
That should not be the case. We should:
* use syslog and log important stuff to /var/log/autoqa.log or similar
* send an email about failed scheduling to autoqa-results
That way we will know something is wrong and will be able to fix it.
Otherwise it just silently fails and we don't know about it.
Feel free to reassign the ticket if you want to work on it.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/196>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 6 months
iso watcher, post-iso-build event, mediakit_sanity test patch for review
by Hongqing Yang
Hi, all,
Included are package for iso watcher, which use lftp to mirror dl.fp.org/pub/alt/stage and kick off mediakit_sanity test,
package for post-iso-build event, and package for mediakit_sanity test which test the iso's size, md5, sha256sum, repoclosure
and file conflicts.
During the first run of /iso/watcher.py, it will mirror all the isos at dl.fp.org/pub/alt/stage and kick off mekiakit_sanity test,
after that, it will only mirror the new isos, the tree compose and deltaiso are not included in the mirror.
This is my maiden work, thanks for your review.
Hongqing
12 years, 7 months
