#217: autoqa job failures --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- After Kamil mentioned this earlier in the week, I noticed not many post- koji-build jobs were processing. Inspecting the logs, it appears they are failing ....
For example, the following traceback comes from http://test1250.test.redhat.com/results/44857-autotest/brutus.test.redhat.co... {{{ 08/19 13:01:22 INFO | autotest:0913| FAIL rpmlint rpmlint timestamp=1282249190 localtime=Aug 19 16:19:50 Unhandled str: Unhandled TypeError: 'NoneType' object is unsubscriptable 08/19 13:01:22 INFO | autotest:0913| Traceback (most recent call last): 08/19 13:01:22 INFO | autotest:0913| File "/usr/share/autotest/common_lib/test.py", line 570, in _call_test_function 08/19 13:01:22 INFO | autotest:0913| return func(*args, **dargs) 08/19 13:01:22 INFO | autotest:0913| File "/usr/share/autotest/common_lib/test.py", line 279, in execute 08/19 13:01:22 INFO | autotest:0913| postprocess_profiled_run, args, dargs) 08/19 13:01:22 INFO | autotest:0913| File "/usr/share/autotest/common_lib/test.py", line 201, in _call_run_once 08/19 13:01:22 INFO | autotest:0913| self.run_once(*args, **dargs) 08/19 13:01:22 INFO | autotest:0913| File "/usr/share/autotest/site_tests/rpmlint/rpmlint.py", line 70, in run_once 08/19 13:01:22 INFO | autotest:0913| collection_name = repoinfo.getrepo_by_tag(kojitag)['collection_name'] 08/19 13:01:22 INFO | autotest:0913| TypeError: 'NoneType' object is unsubscriptable 08/19 13:01:22 INFO | autotest:0913| 08/19 13:01:22 INFO | autotest:0913| None 08/19 13:01:22 INFO | autotest:0913| END FAIL rpmlint rpmlint timestamp=1282249190 localtime=Aug 19 16:19:50 }}}
This AutoQA instance is running the older 0.3 branch. I gather the tests have changed significantly since.
#217: autoqa job failures ---------------------+------------------------------------------------------ Reporter: jlaska | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by wwoods):
Replying to [ticket:217 jlaska]:
{{{ File "/usr/share/autotest/site_tests/rpmlint/rpmlint.py", line 70, in run_once collection_name = repoinfo.getrepo_by_tag(kojitag)['collection_name'] TypeError: 'NoneType' object is unsubscriptable }}}
This says two things to me: 1. `repoinfo.getrepo_by_tag(kojitag)` is returning `None`, which probably means the koji tag is not present in `repoinfo.conf`. So what's the koji tag for this test? 1. The test should more gracefully handle this failure: {{{ repo = repoinfo.getrepo_by_tag(kojitag) if repo is None: raise error.TestError("Could not find repoinfo for koji tag: %s" % kojitag") }}}
#217: autoqa job failures ---------------------+------------------------------------------------------ Reporter: jlaska | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by kparal):
From the control file: http://test1250.test.redhat.com/results/44857-autotest/brutus.test.redhat.co... {{{ envr='gbdfed-1.5-3.fc15' autotest_server='test1250.test.redhat.com' kojitag='dist-f15' name='gbdfed' }}}
I think dist-f15 is simply not defined in our repoinfo.conf that is present on our production instance.
#217: autoqa job failures ---------------------+------------------------------------------------------ Reporter: jlaska | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Comment (by kparal):
Replying to [comment:1 wwoods]:
- The test should more gracefully handle this failure:
Patch '[PATCH] don't crash when repoinfo.getrepo_by_tag returns None' sent to autoqa-devel.
#217: autoqa job failures ---------------------+------------------------------------------------------ Reporter: jlaska | Owner: jlaska Type: defect | Status: assigned Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Resolution: | Keywords: ---------------------+------------------------------------------------------ Changes (by jlaska):
* owner: => jlaska * status: new => assigned
Comment:
Ah, thanks wwoods and kparal. For part#1, the ''repoinfo.conf'' for our production instance contains the following rawhide and f14 sections:
{{{ # Rawhide [rawhide] arches = i386, x86_64 path = development/rawhide url = %(rawhideurl)s tag = dist-f15 collection_name = devel
# Fedora 14 [f14] path = development/14 url = %(rawhideurl)s collection_name = F-14
[f14-updates] path = 14 url = %(updatesurl)s parents = f14 collection_name = F-14
[f14-updates-testing] path = testing/14 url = %(updatesurl)s parents = f14-updates, f14 collection_name = F-14 }}}
'''BUT''' ... I broke procedure here. Mental note for next time ... whenever we deploy a repoinfo.conf change, I need to either: 1. Update the autoqa release and deploy new packages to server+clients 2. Or, make the appropriate repoinfo.conf change on the server '''and''' the clients.
This is my fault folks ... bad jlaska!
For now ... 1. I've updated the repoinfo.conf configuration on the clients, this should get tests flowing again. 2. I'm updating [https://fedoraproject.org/wiki/How_to_update_AutoQA_repoinfo.conf How_to_update_AutoQA_repoinfo.conf] so I don't do this again
I'll leave this ticket open until the jobs are flowing again, and the patch proposed by Kamil is included in master. Thanks all!
#217: autoqa job failures ---------------------+------------------------------------------------------ Reporter: jlaska | Owner: jlaska Type: defect | Status: closed Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Resolution: fixed | Keywords: ---------------------+------------------------------------------------------ Changes (by kparal):
* status: assigned => closed * resolution: => fixed
Comment:
The issue seems fixed: https://fedorahosted.org/pipermail/autoqa-devel/2010-August/001031.html
Closing this ticket - if the problem arises again, please reopen, thanks.
autoqa-devel@lists.fedorahosted.org
-
fedora-badges