autoqa-devel April 2010

autoqa-devel@lists.fedorahosted.org

7 participants
65 discussions

[AutoQA] #145: ResultsDB: create resultsdb prototype - create simple frontend
by fedora-badges 13 Apr '10

13 Apr '10

#145: ResultsDB: create resultsdb prototype - create simple frontend ----------------------------+----------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: major | Milestone: Resultdb Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- sub-task for #134. Create simple frontend, which will show state and results of tests using resultsdb. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/145> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

Update to autoqa-0.3.2
by James Laska 12 Apr '10

12 Apr '10

Greetings, I'd like to update and deploy a new autoqa package. I've listed the changes in the spec file patch attached. This updated package will allow additional testing of the new initscripts tests. Comment/concerns encouraged. Thanks, James

2 3

[AutoQA] #140: pst: Testing packages using Koji hook
by fedora-badges 12 Apr '10

12 Apr '10

#140: pst: Testing packages using Koji hook --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Package Sanity Tests Component: tests | Version: 1.0 Keywords: pst | --------------------+------------------------------------------------------- At first, we will probably employ sanity testing using Bodhi hook, because it seems easier to implement and it is probably more useful. But later on, will we also strive to do sanity testing also on packages just built in Koji (using the Koji hook, i.e. not related whether they travel to Bodhi or not)? I suppose so. But how do we do it? The main problems are probably the dependencies, which may not be available in any repository. Will we be able to solve these issues somehow? Or will we for example test only those packages that won't have outstanding dependencies, neglecting the others? We will have to have a look into this issue. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/140> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

[AutoQA] #128: pst: Create a mechanism to ensure test clients are fully up-to-date
by fedora-badges 12 Apr '10

12 Apr '10

#128: pst: Create a mechanism to ensure test clients are fully up-to-date --------------------+------------------------------------------------------- Reporter: kparal | Owner: Type: task | Status: new Priority: major | Milestone: Package Sanity Tests Component: tests | Version: 1.0 Keywords: tps | --------------------+------------------------------------------------------- For sanity tests we will need that the test client machines are always fully up-to-date. We must think about a mechanism that will provide that for us. Will we have some kind of periodic task that will connect to all clients and update them? Or should the TPS test itself ensure the machine is up- to-date and only after that start executing itself? What about reboot? How do we know when it is necessary to reboot after an update? Will we reboot after each update, just to be sure nothing got broken? -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/128> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 4

[AutoQA] #135: ResultsDB: define default (common) key-values for basic test classes
by fedora-badges 12 Apr '10

12 Apr '10

#135: ResultsDB: define default (common) key-values for basic test classes -----------------------+---------------------------------------------------- Reporter: jskladan | Owner: kparal Type: task | Status: new Priority: major | Milestone: Resultdb Component: docs/wiki | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- We have more types/classes of tests (e.g. package tests, installation tests, repo tests...). For each of these we want to store different 'extra information'. These key-value pairs will then be used for the frontends etc. We do not actually want to strictly command the test writers to use these key-value pairs, but our frontends will of course require their presence. On the other hand, test writers can use their own key-value pairs and create their own frontends as they like. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/135> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges 09 Apr '10

09 Apr '10

1 0

[AutoQA] #119: Update koji_utils.py and repoinfo.conf to accomodate new NFR paths
by fedora-badges 08 Apr '10

08 Apr '10

#119: Update koji_utils.py and repoinfo.conf to accomodate new NFR paths -------------------------+-------------------------------------------------- Reporter: jlaska | Owner: jlaska Type: enhancement | Status: new Priority: major | Milestone: Fedora 13 Component: watchers | Version: 1.0 Keywords: | -------------------------+-------------------------------------------------- To accommodate the new URLs for 'no frozen rawhide' (see http://lists.fedoraproject.org/pipermail/devel- announce/2010-February/000574.html), several changes are needed so that autoqa detects the builds and looks in the correct repos to find previous packages. See patch sent to list for review (https://fedorahosted.org/pipermail /autoqa-devel/2010-February/000208.html) -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/119> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

Testing instance of autotest+autoqa - how to get it up'n'running
by Josef Skladanka 07 Apr '10

07 Apr '10

Hi, i'd like to test the suggestion from LMR about propagating autotest test_id to the client side, so i set up RHEL 5.4 box with autotest-server (according to the <https://fedoraproject.org/wiki/Install_and_configure_autotest>) and FC12 with AutoQA instance. My questions: 1) How do i connect these two? I.E. how do i tell AutoQA that 'use this autotest server'. 2) Do i need to set up another box as a client for autotest, or will the one with AutoQA do? 3) How do i make autoqa to schedule a new autotest test - i suppose i can extract the command from the wathers? Joza

2 1

Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges 07 Apr '10

07 Apr '10

1 0

Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges 06 Apr '10

06 Apr '10

#87: new post-bodhi-update hook ----------------------+----------------------------------------------------- Reporter: wwoods | Owner: wwoods Type: task | Status: assigned Priority: major | Milestone: autoqa depcheck Component: harness | Version: 1.0 Resolution: | Keywords: ----------------------+----------------------------------------------------- Comment (by wwoods): So it turns out there's currently no way to distinguish between 'New' and 'Requested' and there's no difference between 'Requested' and 'Pending' ''except'' for critpath updates. According to lmacken on IRC: {{{ The only statuses in bodhi are: pending, testing, stable, obsolete. The only requests are: testing, stable, obsolete. }}} Normal updates start with {status: pending, request: (testing or stable)}. request defaults to 'testing'. Critpath updates start with {status: pending, request: None}, and once they have gotten enough karma, the submitter is then allowed to actually make the request. Once pushed, they have (status: (testing or stable)). This means that we currently have no way of knowing what request (i.e. which repo) a pending update is targeting. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/87#comment:8> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel April 2010