Some Depcheck runs taking long time
by Josef Skladanka
Hello,
yesterday, Kamil spotted some depcheck run, which took quite a lot of time.
It was caused by the depcheck_pretty() routines, which took some time to parse those 70k lines of text. Sadly, this is not-a-bug, but a feature. The positive thing is, that logs this long are not common and mostly sign a error in dependencies.
J.
12 years, 10 months
HTML results and highlight links
by James Laska
Greetings,
I finally found a depcheck failure report that I could use to checkout
some of the coolness coming in autoqa-0.5.0. First off, these results
look *so* much better than text/plain reports, and it's really easy to
find the failure information. Nice work on 0.5.0!
I was talking to jskladan about the links (>>) in the highlight section.
The character is small, and it didn't occur to me that it was a
clickable link at first. We discussed changing the link to make it more
obvious that it is intended to be clicked. I mocked up a few basic
samples and Joza suggested I send them to the list for feedback.
http://jlaska.fedorapeople.org/libreport-2.0.3-1.fc.html
Any preferences?
Thanks,
James
12 years, 10 months
0.5.0 testing status
by Kamil Paral
This a status report from our current 0.5.0 testing effort:
1. The tests seem to work properly (except for one Koji timeout and one NoMoreMirrorsRepoError yum error).
2. The number of items in the mailing list increased substantially, because we send one email for the full.log and one email for every (pretty) log created. Rpmlint equals two emails, upgradepath may equal to 10-20 emails. The mailing list is not much human readable now. We can make adjustments if you want. Personally I consider the list as another kind of storage place and I don't really mind.
3. We have found an issue with koji/bodhi watcher that caused every test to be scheduled multiple times. When asking Koji/Bodhi takes really long time, another watcher can be run in parallel. But the subsequent watcher still operates with the old data, thus resulting in scheduling the same tests as the first one. We have seen this issue happening also on our current production instance:
https://fedorahosted.org/pipermail/autoqa-results/2011-June/thread.html - search for q4wine
Jskladan already sent an example patch to tflink to examination, I believe a proper patch will appear on the ML/in git soon if we confirm it fixes the issue.
4. We have identified an issue where our email reduction does not work, it does not send email when it is supposed to (when both depchecks pass for an -updates-testing update). The root cause if not known yet.
I suppose it will take a few days until the problems are identified and fixed.
12 years, 10 months
[AutoQA] #343: Bodhi Comment Email Logic is not Detecting Tests
by fedora-badges
#343: Bodhi Comment Email Logic is not Detecting Tests
--------------------+-------------------------------------------------------
Reporter: tflink | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: 0.5.0
Component: core | Keywords:
--------------------+-------------------------------------------------------
The logic used to determine whether or not to send an email with bodhi
comments is not working.
Example of what should have been INCOMPLETE to PASS:
{{{
06/13 11:07:13 INFO | test:0383| Submitting results (log, email,
bodhi) for: depcheck: PASSED; 1 PASSED for phpMyAdmin-3.4.2-1.fc14
06/13 11:07:13 INFO | test:0308| Log created:
/usr/share/autotest/results/default/depcheck/results/phpMyAdmin-3.4.2-1.f.html
06/13 11:07:13 INFO | test:0254| Email not sent: "depcheck: PASSED; 1
PASSED for phpMyAdmin-3.4.2-1.fc14"
06/13 11:07:20 INFO |bodhi_upda:0101| Current State of update
phpMyAdmin-3.4.2-1.fc14 :
06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch':
'x86_64', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13,
14, 52, 1)}
06/13 11:07:20 INFO |bodhi_upda:0101|
06/13 11:07:20 INFO |bodhi_upda:0101| Current State of update
phpMyAdmin-3.4.2-1.fc14 :
06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch':
'x86_64', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13,
14, 52, 1)}
06/13 11:07:20 INFO |bodhi_upda:0101| {'result': 'PASSED', 'arch':
'i386', 'testname': 'depcheck', 'time': datetime.datetime(2011, 6, 13, 15,
7, 20, 855416)}
06/13 11:07:20 INFO |bodhi_upda:0101|
06/13 11:07:20 INFO |bodhi_util:0390| update state : INCOMPLETE to
INCOMPLETE
06/13 11:07:20 INFO |bodhi_util:0275| Bodhi email will NOT be sent
}}}
This logic needs to properly detect the tests that have been run.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/343>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 10 months
[AutoQA] #341: create watcher to download iso images one time during test
by fedora-badges
#341: create watcher to download iso images one time during test
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner:
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: core | Keywords:
----------------------+-----------------------------------------------------
test wrapper will download the iso images for each run if we use the
watcher to monitor the website for the images and trigger the test. James
gave a multi-stage download solution. [[BR]]
* running a squid proxy on your autotest-server to cache
the ISO downloads so that clients really only download
the image 1 time.[[BR]]
* implementing some two-step ISO download process. Step
one is a autotest server job (initiated by a watcher)
that caches the ISO's in an NFS ro mount point
(e.g. /var/cache/autoqa/install-isos). Step two is
another ISO watcher that
monitors /var/cache/autoqa/install-isos and initiates
tests when new content is available[[BR]]
I have written a samll script to watch the iso images at /var/cache/autoqa
/install-isos[[BR]]
7a6087849aa7b526caf8e2886fb2b0166e328480[[BR]]
I checked the existence and updated time to determine if it is a new one.
I am not familiar with this part, do you have any idea about this?
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/341>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 10 months
Re: Fedora 14 Update: lvm2-2.02.84-2.fc14
by Kamil Paral
> Mike McLean wrote:
> > lvm2-2.02.84-2.fc14 has a higher NVR than the current F15 build
> > (lvm2-2.02.84-1.fc15). Shouldn't some sanity check have caught this,
> > or am I missing something?
>
> AutoQA complains about these kind of things, but most maintainers
> don't read
> AutoQA complaints, probably because:
> * AutoQA always comments, even if everything is OK, and
This will be solved in the next AutoQA release, in a week or so.
> * there are also false positives, e.g. when a corresponding F15 update
> is
> already queued at the same time.
It is not really a false positive, because AutoQA can't be sure the builds will be pushed in the right order (or that F15 update will not be unpushed in the meantime). But we will definitely improve the output, unfortunately not in the next release.
>
> Both these issues cause real upgrade path bugs to go unnoticed.
>
> Kevin Kofler
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
12 years, 10 months
[AutoQA] #315: Create per-item logs for multi-item tests
by fedora-badges
#315: Create per-item logs for multi-item tests
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: 0.5.0
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently multi-item tests (like upgradepath that is testing multiple
updates at once) create one big log. That confuses some maintainers.
Create a small separate log for every item tested and then link only this
log in Bodhi comments.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/315>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 10 months
