[PATCH] #412 - Depcheck crash: KeyError
by Josef Skladanka
I'v added try-except block around the critical area.
Kamil and I found out, that this error happens, when packagers push new
builds into Bodhi update, in the time of depcheck-run on the respective
update (to be more specific, after we query Koji for -pending builds,
and before we sum-up the build results to update results).
If this happens, we now add the build do problematic builds list (with
appropriate error message), which subsequently FAILs the update.
=======================================================================
diff --git a/tests/depcheck/depcheck.py b/tests/depcheck/depcheck.py
index 819748f..ea101f0 100644
--- a/tests/depcheck/depcheck.py
+++ b/tests/depcheck/depcheck.py
@@ -340,8 +340,21 @@ class depcheck(AutoQATest):
desc = 'Update %(result)s: %(title)s\n'
.
for build in update['builds']:
+ # Sometimes, update is changed during depcheck testrun
+ # and new build (which was not in -pending at the start)
+ # is added. When this happens, we want to skip the build
+ # and mark it as problematic (to subsequently fail the.
+ # update)
+ try:
+ td.output.append(digest.digest[build['nvr']]['all'])
+ except KeyError:
+ msg = "Build %s is part of update '%s', but it was " \
+ "added during the depcheck run" % (build['nvr'], update['title']))
+ self.log(msg, stderr = True, highlight = True, details = td)
+ td.update_result("ABORTED")
+ self.problematic[build['nvr']] = msg
+ continue
.
- td.output.append(digest.digest[build['nvr']]['all'])
td.output.append("\n\n")
for h in digest.digest[build['nvr']]['highlights']:
td.highlights.append((h, None))
@@ -349,7 +362,7 @@ class depcheck(AutoQATest):
if build['nvr'] not in pending_ok:
msg = "Build %s is part of update '%s', but it wasn't " \
"scheduled for testing" % (build['nvr'], update['title'])
- self.log(msg, strerr = True, highlight = True, details = td)
+ self.log(msg, stderr = True, highlight = True, details = td)
td.update_result('ABORTED')
self.problematic[build['nvr']] = msg
continue
12 years, 1 month
[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges
#255: Use Config class to simplify access to configuration options
--------------------+-------------------------------------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone:
Component: core | Keywords:
--------------------+-------------------------------------------------------
Currently all our libraries and tests use ConfigParser and parse our
configuration files (autoqa.conf, fas.conf, etc) directly. That is not
ideal, it involves many lines of code, converting to correct variable
types (int, bool), handling default values, and so on.
We should create a Python class Config, which is initialized once in the
beginning, and then can be access globally and easily from any other
module. It will handle default values and type conversion centrally in one
place. Also access will be much easier.
PS: We already have autoqa.config module. Maybe we just don't use it?
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/255>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
[AutoQA] #350: Add support for using file proxy
by fedora-badges
#350: Add support for using file proxy
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Future tasks
Component: core | Keywords:
-------------------------+--------------------------------------------------
Currently we allow to cache downloaded RPMs with allow_pkg_cache in
autoqa.conf. That uses our own code in util.py:download().
Tim was talking about using file proxy and it now seems to me as a far
better approach. It can cache more files (like yum metadata, ISO files,
etc). The proxy can run on the same computer or on some local-network
computer. Several computers can share the same proxy. We don't have to
care about storing the files and cleaning up the directories. It means
less code. It's transparent for us.
The task now is to play with some proxy, try whether it works, implement
some support for AutoQA (if required), and document the process of setting
it up (probably in [https://fedoraproject.org/wiki/AutoQA_Development
here]).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/350>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
[AutoQA] #394: All tests must have their maintainer defined
by fedora-badges
#394: All tests must have their maintainer defined
---------------------+-------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: minor | Milestone: Finger Food
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+-------------------------
Occasionally we are running into issues with tests for which we are not
sure who to ask help with. Every test should have its "maintainer"
defined. The maintainer is a person who to ask about implementation
details or who to harass about bugs.
Currently the autotest's control file contains AUTHOR="..." line. Maybe we
should use that for maintainer definition (even though it might be a
little misleading). Or maybe we should define and use a MAINTAINER="..."
variable.
The task is:
1. Find the best way where to define each test's maintainer
(AUTHOR/MAINTAINER inside control file, etc).
2. Decide whether we need to check its existence.
3. Find maintainers for every test present inside AutoQA and fill it in
inside the source code.
4. Amend the documentation.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/394>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
[AutoQA] #390: update rats_install
by fedora-badges
#390: update rats_install
----------------------+-----------------------------------------------------
Reporter: hongqing | Owner: hongqing
Type: task | Status: new
Priority: major | Milestone: Automate installation test plan
Component: core | Keywords:
----------------------+-----------------------------------------------------
rats_install does not work after F14. after investigating in it, The
following things should be updated:[[BR]]
1. install.img is compressed into initrd.img, remove the exist check
2. initrd.img is compressed as XZ compressed file instead of gzip
compressed file, gzip in python has to be replaced
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/390>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges
#338: AutoQATest.version - is it needed?
-------------------------+--------------------------------------------------
Reporter: kparal | Owner:
Type: enhancement | Status: new
Priority: trivial | Milestone: Finger Food
Component: tests | Keywords:
-------------------------+--------------------------------------------------
In all our tests we have code like this:
{{{
class rpmlint(AutoQATest):
version = 1 # increment if setup() changes
}}}
The question is - is the ''version'' attribute needed and being used at
all? I have never seen any difference in behavior, the setup() phase is
run every time.
We should have look at autotest documentation or source code whether this
is being used and when. If we don't need it, let's remove it from all our
tests and templates (the less code the better).
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/338>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
12 years, 1 month
