[AutoQA] #333: create physical disk on guest to store image
by fedora-badges
#333: create physical disk on guest to store image
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Keywords:
----------------------+-----------------------------------------------------
In order to install from hard drive, we have to install one system and
create a physical partition to store the image, then we can boot a new
system to test it.
please refer test case:
https://fedoraproject.org/wiki/QA/TestCases/InstallSourceHardDrive
we have already had the script to create a disk partition to store the
kickstart file in DVD installation using guestfs.
I think this should also works for the image, but the image is much more
large than ks file. it may take long time.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/333>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 11 months
[AutoQA] #208: update minimon to transport logs between guest and host via virtio
by fedora-badges
#208: update minimon to transport logs between guest and host via virtio
-------------------+--------------------------------------------------------
Reporter: liam | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: tests | Version: 1.0
Keywords: |
-------------------+--------------------------------------------------------
Since minimon has to use network during test, some test cases will not
activate network during test,in this case, minimon can not transport logs
to host, test also be identified fail even it was successfully run.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/208>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 11 months
[AutoQA] #331: Change loading of config files, so that autoqa can be run from the gitdir
by fedora-badges
#331: Change loading of config files, so that autoqa can be run from the gitdir
-------------------------+--------------------------------------------------
Reporter: vhumpa | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Future tasks
Component: core | Keywords:
-------------------------+--------------------------------------------------
Go through all of the AutoQA and modify it so that in addition to the
/etc/autoqa also the in-gitdir conf directory is polled for the *.conf
files. Also, the lib/autoqa libraries need to be available in site-
packages, so consider ways of (sym?)linking them there, if the machine
doesn't have them installed or you need to test code that is a part of
them.
This should result in watchers, the autoqa script and possibly more parts
to be able to run from the source directory. This can make certain types
of code testing less harassing in a way of not having to use the VM at all
times.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/331>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 11 months
Is AutoQA Ready for a Release
by Tim Flink
During the phone conference two weeks ago, we talked about trying to
release more frequently. The goal that I remember setting is evaluating
release readyness every 2 weeks.
It has been 2 weeks since then and it's time to evaluate release ready-ness!
Unless there is something that I'm not understanding, my vote would
currently be "no". I'd like to see the spam-reduction code in place
before we make the first release - I should have something pushed up to
a git branch for initial review in the next day or so.
Any other thoughts?
Tim
12 years, 11 months
Depcheck content filter ;-)
by Josef Skladanka
Hi gang,
this week, I've been working on a script for filtering out build-specific information from depcheck.
This is rought version which works over the 'client.DEBUG' file, and I'm currently polishing it up,
so it can be used from inside the depcheck.py wrapper (most of the code would be the same though).
Usage is simple - python depcheck_digest.py path_to_debug_log
For some reason zimbra won't let me attach the file, so please download it from this link:
http://jskladan.fedorapeople.org/depcheck_digest.tar
There is the script and some sample logs, but feel free to run it on current results and
see whether it's working all right.
Joza
12 years, 11 months
ResultsDB status
by John Dulaney
Since I'm getting back into Fedora QA work after a series of major life disruptions, including the
loss of everything I had done previously, I figure the easiest thing for me to work on is that which
I was working on before; ResultsDB.
So, what has been done along these lines since August?
12 years, 11 months
disable Bodhi comments?
by Kamil Paral
Today I had a chat with mcepl, our Czech package maintainer (attached below). I have received similar questions several times in the last few days. I start to have some tendencies towards making a poll and ask package maintainers whether they consider current AutoQA test results beneficial, or whether they would like to see them temporarily disabled, until we fix current shortcomings (unfortunately some of them are hard to fix easily). I have at least created some blogposts [1] [2], but that's probably not enough.
It seems that AutoQA have started with too broad scope and now, even though we try, we can no longer make it do one thing and do it properly, because there are simply too many things on our plate.
Thoughts?
[1] http://kparal.wordpress.com/2011/05/10/missing-autoqa-logs/
[2] http://kparal.wordpress.com/2011/05/10/autoqa-why-upgradepath-test-fails-...
=====
mcepl: kparal: there is something wrong ... compare http://autoqa.fedoraproject.org/results/94742-autotest/qa01.c.fedoraproje... and https://admin.fedoraproject.org/updates/search/wordpress. I just see wordpress updates for all branches .... what's wrong?
kparal: mcepl: upgradepath will continue to fail for F15 until both F13 and F14 updates are pushed to stable updates
mcepl: but isn't it a bug in QA? Shouldn't it also consider available packages also in -testing?
kparal: mcepl: argh, I said it wrong. F13 will continue to fail until F14 and F15 updates are pushed
kparal: mcepl: F14 will continue to fail until F15 update is pushed
kparal: mcepl: basically, we are trying to ensure that upgradepath constraint is fulfilled at all times
kparal: mcepl: that means that F13 update must be not pushed earlier than F14 update
kparal: that would break upgradepath
kparal: of course they can be pushed simmulataneously
kparal: but we are not able to check that yet :/
mcepl: kparal: I have pushed all of them in the same time (plus minus a minute) ... shouldn't AutoQA know about it (they are they being asked to be pushed)?
mcepl: I am afraid you are in grave danger to learn people they should ignore those reports as a useless junk (see Abrt ;))
kparal: mcepl: yes, you're right. we should be able to say "wordpress-3.1.2-1.fc13, wordpress-3.1.2-1.fc14 and wordpress-3.1.2-1.fc15 can be pushed together. but you can't push only one of them, unless it is the f15 one"
kparal: but we can't really do that now using bodhi comments
mcepl: OK, shutting up. </rant>
kparal: it's planned for mid-term future
mcepl: I would be very afraid of that "mid-term" .... you may find packagers well trained to ignore your reports meanwhile.
kparal: mcepl: do you think it's better to shut down the reports completely?
mcepl: no ... but to make it higher priority IMHO. But I won't write the code, so (as I said) shutting up.
mcepl: or maybe yes ... shutting them down for a while.
kparal: mcepl: actually it's the top priority. but it will still take some time
kparal: mcepl: we'll discuss that in a team. thanks for your opinion
mcepl: kparal: wouldn't it be possible just to include a bit of delay (5 minutes or so) and then check all requests for push which happened more or less in the same moment?
mcepl: *delay before the AutoQA tests are run.
mcepl: that could be simpler to do, wouldn't it?
kparal: mcepl: yes, but still, we don't really have any means to communicate to releng team "you must push all these 3 updates at once, or none at all". yet.
mcepl: yeah, that's the problem
12 years, 11 months
