autoqa-devel January 2011

autoqa-devel@lists.fedorahosted.org

7 participants
78 discussions

[AutoQA] #208: update minimon to transport logs between guest and host via virtio
by fedora-badges 20 May '11

20 May '11

#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

1 4

[AutoQA] #238: Move ResultsDB to Turbogears2 application
by fedora-badges 28 Apr '11

28 Apr '11

#238: Move ResultsDB to Turbogears2 application ----------------------------+----------------------------------------------- Reporter: jskladan | Owner: jskladan Type: task | Status: new Priority: major | Milestone: Resultdb Component: infrastructure | Keywords: ----------------------------+----------------------------------------------- Because the current implementation has noticeable disadvantages (speed, database management, ...), I'd like to rewrite the resultsdb backend using TG2. This will also provide a json-rpc, added to the xml-rpc interface. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/238> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #230: upgradepath: current implementation is broken when pushing older packages
by fedora-badges 27 Apr '11

27 Apr '11

#230: upgradepath: current implementation is broken when pushing older packages --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Currently upgradepath takes into account only the given NVR and compares it with other repositories. This approach works, except for one use case - when you want to push an older package version into the repository. Technically you can have multiple package versions in a single repository. Yum prefers the most recent one, but you can have more of them there. It's hard to imagine a use case where you want to push an older version, but let's say for example an older kernel that is needed for hardware compatibility reasons. In this case, our current upgradepath fails - it supposes the given NVR is always the latest. We need to modify upgradepath in such a way, that is supposes that given NVR has been pushed into the repository and then traverses all repositories from bottom up and checks for upgradepath constraint everywhere - including the repo you pushed into, including all package versions which might be there. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/230> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #214: conflicts: fails with parent repositories
by fedora-badges 22 Apr '11

22 Apr '11

#214: conflicts: fails with parent repositories --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- These two commands work (although the package counts are somewhat weirdly same): {{{ # repoclosure --tempcache --newest --repofrompath=target,http://download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/x86_64/os --repoid=target Added target repo from /root/http:/download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/x86_64/os Reading in repository metadata - please wait.... Checking Dependencies /usr/lib/python2.6/site-packages/yum/packages.py:401: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if prcotuple in self.prco[prcotype]: Repos looked at: 1 target Num Packages in Repos: 20806 }}} {{{ # repoclosure --tempcache --newest --repofrompath=target,http://download.fedoraproject.org/pub/fedora/linux/updates/13/x86_64 --repoid=target Added target repo from /root/http:/download.fedoraproject.org/pub/fedora/linux/updates/13/x86_64 Reading in repository metadata - please wait.... Checking Dependencies /usr/lib/python2.6/site-packages/yum/packages.py:401: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal if prcotuple in self.prco[prcotype]: Repos looked at: 1 target Num Packages in Repos: 20806 }}} But if you combine it: {{{ # repoclosure --tempcache --newest --repofrompath=target,http://download.fedoraproject.org/pub/fedora/linux/updates/13/x86_64 --repoid=target --repofrompath=parent1,http://download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/x86_64/os --repoid=parent1 Added target repo from /root/http:/download.fedoraproject.org/pub/fedora/linux/updates/13/x86_64 Added parent1 repo from /root/http:/download.fedoraproject.org/pub/fedora/linux/releases/13/Everything/x86_64/os Reading in repository metadata - please wait.... Cannot retrieve repository metadata (repomd.xml) for repository: parent1. Please verify its path and try again Some dependencies may not be complete for this repository Run as root to get all dependencies or use -t to enable a user temp cache Checking Dependencies Cannot retrieve repository metadata (repomd.xml) for repository: parent1. Please verify its path and try again }}} Something is broken here. {{{ yum-utils-1.1.28-1.fc13.noarch yum-metadata-parser-1.1.4-1.fc13.x86_64 yum-3.2.27-4.fc13.noarch }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/214> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

[AutoQA] #218: re-use fedora-qa script for checking PackageReviewGuidelines
by fedora-badges 07 Apr '11

07 Apr '11

#218: re-use fedora-qa script for checking PackageReviewGuidelines --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Future test cases Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Aurélien Bompard has written a "fedora-qa" tool, which checks all the MUST items in !PackageReviewGuidelines that are not covered by rpmlint. http://fedoraproject.org/wiki/AurelienBompard#QA There's a high possibility that we could re-use parts of his code for several new AutoQA test cases. Worth investigating. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/218> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #262: Rethink the watcher/event/test architecture
by fedora-badges 29 Mar '11

29 Mar '11

#262: Rethink the watcher/event/test architecture --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- We've hit the limits of our architecture. The one watcher-one event style is no longer sufficient. We need to think about our needs and change that architecture, so that we are more flexible with watchers, events, target architectures, batch scheduling, etc. I have mentioned some bits at: https://fedorahosted.org/pipermail/autoqa-devel/2011-January/001522.html Let's refactor the architecture and get rid of many hacks that are currently necessary. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/262> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #245: Add support for test re-scheduling
by fedora-badges 29 Mar '11

29 Mar '11

#245: Add support for test re-scheduling --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: 0.5.0 Component: core | Keywords: --------------------+------------------------------------------------------- After we start sending results to Bodhi/ResultDB there will immediately emerge a need for test re-scheduling. There may be different reasons for that: 1. Something went wrong in the test execution, we need to run it again. 2. The environment has changed and test needs to be executed once again. For example the upgradepath test for some update failed because of invalid package versions in higher Fedora releases. That problem has been corrected and we need now a new execution of the test. The important thing is that the maintainer should be able to trigger the re-scheduling, not just us. Find a way how to properly reschedule tests (we will probably utilize ResultDB for that) and add that functionality. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/245> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #213: remove collection_name from repoinfo.conf
by fedora-badges 29 Mar '11

29 Mar '11

#213: remove collection_name from repoinfo.conf ----------------------------+----------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: minor | Milestone: Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- Once ticket #212 is complete we have no real need for collection_name anymore; remove it from repoinfo.conf. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/213> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #212: fix check_opt_in to not use collection_name
by fedora-badges 29 Mar '11

29 Mar '11

#212: fix check_opt_in to not use collection_name -----------------------+---------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: minor | Milestone: Component: docs/wiki | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- collection_name was used to line up with the dist-cvs branch layout; now that we have switched to dist-git/fedpkg the branch names match the repo names used in repoinfo, so we have no need for collection_name. This will require modifying the existing autoqa-optin file structure to match the git layout. We can leave symlinks for the old ('F-14') distro names but use the new ones ('f14') as the canonical ones. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/212> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #249: upgradepath: support check-whole-distro mode
by fedora-badges 29 Mar '11

29 Mar '11

#249: upgradepath: support check-whole-distro mode -------------------------+-------------------------------------------------- Reporter: kparal | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: tests | Keywords: -------------------------+-------------------------------------------------- This is a suggestion proposed by [https://fedoraproject.org/wiki/User:Spot spot] at [https://fedoraproject.org/wiki/Fedora_14_QA_Retrospective#Wishlist Fedora 14 QA Retrospective]: ''Upgradepath - Need to schedule upgradepath test runs against the entire distro, not just for each bodhi build. Also, adjust release criteria accordingly'' We could add mode that allows this. This script could then be used for ensuring all the packages in the whole distribution have upgrade path criteria met. This could be useful to check for example right before a new Fedora is going to be released. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/249> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel January 2011