Update to autoqa-0.3.2
by James Laska
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
14 years
[AutoQA] #140: pst: Testing packages using Koji hook
by fedora-badges
#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
14 years
[AutoQA] #128: pst: Create a mechanism to ensure test clients are fully up-to-date
by fedora-badges
#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
14 years
[AutoQA] #135: ResultsDB: define default (common) key-values for basic test classes
by fedora-badges
#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
14 years
Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges
#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):
Bodhi is currently undergoing some serious rewriting/architecture changes,
so we can plan on it having that capability in the future. But right now
it doesn't know where critpath updates are headed. We'll just have to test
against both repos until that's fixed, I guess.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/87#comment:10>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
14 years
Testing instance of autotest+autoqa - how to get it up'n'running
by Josef Skladanka
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
14 years
Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges
#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 kparal):
I have not understood fully the description, but I would like to point
out, that for our Package Sanity Testing it is quite essential to know
whether the update is about to go to updates-testing or stable updates. I
suppose we will need it also for other tests.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/87#comment:9>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
14 years
Re: [AutoQA] #87: new post-bodhi-update hook
by fedora-badges
#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
14 years
