autoqa-devel February 2012

autoqa-devel@lists.fedorahosted.org

9 participants
44 discussions

[AutoQA] #373: ResultsDB: Add 'store to ResultsDB' functionality to test.py
by fedora-badges 14 Mar '12

14 Mar '12

#373: ResultsDB: Add 'store to ResultsDB' functionality to test.py ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: jskladan Type: task | Status: new Priority: major | Milestone: 0.7.0 Component: resultdb | Keywords: ----------------------+----------------------------------------------------- In order to store data into resultsdb, we need to create a method which will access resultsdb's XMLRPC interface and store data from inside the post_results() method. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/373> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #255: Use Config class to simplify access to configuration options
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 6

[AutoQA] #350: Add support for using file proxy
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 9

[AutoQA] #394: All tests must have their maintainer defined
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 4

[AutoQA] #390: update rats_install
by fedora-badges 07 Mar '12

07 Mar '12

#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

1 25

[AutoQA] #338: AutoQATest.version - is it needed?
by fedora-badges 06 Mar '12

06 Mar '12

#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

1 5

[AutoQA] #186: Automate media kit sanity tests
by fedora-badges 05 Mar '12

05 Mar '12

#186: Automate media kit sanity tests --------------------+------------------------------------------------------- Reporter: jlaska | Owner: lili Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- This ticket is intended to track automating the mediakit sanity tests (http://fedoraproject.org/wiki/Category:Installer_Image_Sanity_Test_Cases) Discussion already underway, along with code in Liam's private branch. For details see https://fedorahosted.org/pipermail/autoqa- devel/2010-June/000595.html -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/186> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 9

[AutoQA] #392: Check whether compose_tree needs updating for F17 compose changes (treebuilder)
by fedora-badges 05 Mar '12

05 Mar '12

#392: Check whether compose_tree needs updating for F17 compose changes (treebuilder) ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: tflink Type: task | Status: new Priority: major | Milestone: 0.8.0 Component: tests | Keywords: ----------------------+----------------------------------------------------- I don't really grok the details, but I know there have been some changes to the image compose process post-F16, involving a new branch of lorax called treebuilder: https://fedoraproject.org/wiki/Anaconda/Features/Lorax-TreeBuilder wwoods has a guide up at: https://fedoraproject.org/wiki/User:Wwoods/Building_images_with_treebuilder We should check the impact of this change on AutoQA. immediately, does the compose_tree script need updating? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/392> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #408: depcheck: Argument list too long
by fedora-badges 05 Mar '12

05 Mar '12

#408: depcheck: Argument list too long ---------------------+------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: minor | Milestone: Nice to have soon Component: tests | Keywords: Blocked By: | Blocking: ---------------------+------------------------------- {{{ Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/autoqa/decorators.py", line 72, in newf f_result = f(*args, **kwargs) #call the decorated function File "/usr/share/autotest/tests/depcheck/depcheck.py", line 174, in run_once depcheck_output = utils.system_output(cmd, retain_output=True) File "/usr/share/autotest/common_lib/base_utils.py", line 931, in system_output args=args).stdout File "/usr/share/autotest/common_lib/base_utils.py", line 654, in run stderr_level=get_stderr_level(stderr_is_expected)),), File "/usr/share/autotest/common_lib/base_utils.py", line 79, in __init__ stdin=stdin) File "/usr/lib64/python2.7/subprocess.py", line 672, in __init__ errread, errwrite) File "/usr/lib64/python2.7/subprocess.py", line 1202, in _execute_child raise child_exception OSError: [Errno 7] Argument list too long }}} http://autoqa- stg.fedoraproject.org/results/27644-autotest/virt24.qa/depcheck/results/ful… Sometimes we hit system limits. Proposed solution: Write pending builds to one file, accepted builds to a different file, then provide these files using different command line options to depcheck. Place both files in the results directory. I don't think this issue is really hot, because it happens seldom. Putting to "nice to have soon". -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/408> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

[AutoQA] #194: Incorporate automated anaconda storage suite
by fedora-badges 05 Mar '12

05 Mar '12

#194: Incorporate automated anaconda storage suite --------------------+------------------------------------------------------- Reporter: jlaska | Owner: Type: task | Status: new Priority: major | Milestone: Automate installation test plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Chris Lumens has developed a virt-based test suite to automate different disk/storage install scenarios. I've discussed this briefly with Chris, but I'd be interested in seeing his test suite incorporated within autoqa and run on a regular interval (perhaps along-side Liam's install tests). The tests are currently available at http://clumens.fedorapeople.org /anaconda-storage-test/ -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/194> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel February 2012