autoqa-devel July 2010

autoqa-devel@lists.fedorahosted.org

7 participants
85 discussions

[AutoQA] #138: ResultsDB: media wiki as a storage for metadata about tests
by fedora-badges 13 Oct '10

13 Oct '10

#138: ResultsDB: media wiki as a storage for metadata about tests ----------------------------+----------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: major | Milestone: Resultdb Component: infrastructure | Version: 1.0 Keywords: | ----------------------------+----------------------------------------------- Once #135 #136 and #137 are finished, we should create a provider/middle man (probably a library) which will allow us to get information about the respective test and use it for test execution/storing results/displaying results via frontends... -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/138> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 2

[AutoQA] #137: ResultsDB: propose structure for storing metadata about tests on wiki
by fedora-badges 13 Oct '10

13 Oct '10

#137: ResultsDB: propose structure for storing metadata about tests on wiki -----------------------+---------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: major | Milestone: Resultdb Component: docs/wiki | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- We want to use mediawiki as a storage for tests metadata. We should agree on the fields we want to store (e.g. test owner, destructive/non- destructive, average time to complete test etc.) and the format we'll use to store it (probably JSON though). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/137> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #170: Initscript review: net-tools
by fedora-badges 11 Oct '10

11 Oct '10

#170: Initscript review: net-tools ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/170> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #166: Initscript review: iputils
by fedora-badges 11 Oct '10

11 Oct '10

#166: Initscript review: iputils ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: minor | Milestone: Initscripts review Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Check the test according to the <https://fedorahosted.org/autoqa/wiki/initscripts> -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/166> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

[AutoQA] #134: ResultsDB: create resultsdb prototype
by fedora-badges 06 Oct '10

06 Oct '10

#134: ResultsDB: create resultsdb prototype ----------------------+----------------------------------------------------- Reporter: jskladan | Owner: Type: task | Status: new Priority: major | Milestone: Resultdb Component: tests | Version: 1.0 Keywords: | ----------------------+----------------------------------------------------- Create prototype of database and software which will implement dbSchema from #133 and API from #131 This prototype should also include some test suite, which will be used to determine, if all the functionality is OK. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/134> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 1

[AutoQA] #202: testcases for depcheck
by fedora-badges 25 Sep '10

25 Sep '10

#202: testcases for depcheck --------------------+------------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Package Update Acceptance Test Plan - depcheck Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- To be sure that depcheck is operating as expected, we should have a library of test cases for it. These test cases could take the form of a set (or sets) of trivial RPMs that illustrate various possible dependency problems - or a script that generates RPMs like that. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/202> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 6

[AutoQA] #203: make rpmguard run as a post-bodhi-update test too
by fedora-badges 06 Sep '10

06 Sep '10

#203: make rpmguard run as a post-bodhi-update test too --------------------+------------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Multi-hook tests Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Using the multihook capability described elsewhere, make rpmguard run for the post-bodhi-update hook. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/203> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 5

[AutoQA] #123: rpmguard: check upgrade paths between releases
by fedora-badges 31 Aug '10

31 Aug '10

#123: rpmguard: check upgrade paths between releases ----------------------+----------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Component: tests | Version: 1.0 Keywords: rpmguard | ----------------------+----------------------------------------------------- (As pointed out by spot on the devel list: http://lists.fedoraproject.org/pipermail/devel/2010-March/131746.html) We should be emitting warning/error messages if the new package(s) have a higher ENVR than the currently-released package(s) in any newer release. For example, right now a new F11 package should be checked against the corresponding package(s) in the current F12, branched F13, and rawhide repos. This involves a lot of extra repos and metadata, though. It's not a trivial thing to add. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/123> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 14

[AutoQA] #111: depcheck test
by fedora-badges 27 Aug '10

27 Aug '10

#111: depcheck test --------------------+------------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: autoqa depcheck Component: tests | Version: 1.0 Keywords: | --------------------+------------------------------------------------------- Write an actual depcheck test. This test should take, as inputs: * one or more new package builds, and * the name of a target repository for the new build(s) The test should examine the PRCO (provides/requires/conflicts/obsoletes) data for the new package(s) and the PRCO data for the target repository (and all its parent repos). The test should fail if the new builds would cause missing/broken dependencies or unresolveable conflicts in the target repo(s). -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/111> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 8

[AutoQA] #199: Standardize (some) AutoQA test args
by fedora-badges 19 Aug '10

19 Aug '10

#199: Standardize (some) AutoQA test args -----------------------+---------------------------------------------------- Reporter: wwoods | Owner: Type: task | Status: new Priority: major | Milestone: Multi-hook tests Component: docs/wiki | Version: 1.0 Keywords: | -----------------------+---------------------------------------------------- The various hooks that AutoQA provides each have different test args. Some of these arguments are similar or identical across hooks - for example, 'config' applies to all hooks. Each hook also has an argument that represents the name of the thing to be tested, but this varies from hook to hook - it's a reponame for post-repo-update, treename for post-tree- compose, etc. We should document and standardize these argument names so that it's easier to write tests that will run for multiple hooks. For example, maybe all hooks should use 'name' to represent the name of the thing being tested. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/199> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

1 3

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

autoqa-devel July 2010