Tests storing results into the ResultsDB - first spin
by Josef Skladanka
Hello, gang,
I've created a patch, which allows AutoQA tests to store results in resultsdb.
Because of the quite nice design provided by the AutoQATest base class, it's
only new files, and few changes in the base class (23 lines to be exact) :)
Not that I'd want to push it to master or so - just happy that it's working
and the changes were as simple as i hoped :)
Either have a look at the jskladan branch in git, or at the attached patch.
Joza
13 years, 8 months
Re: New branch - multihook_tests
by Kamil Paral
----- "James Laska" <jlaska(a)redhat.com> wrote:
>
> Thanks Kamil,
>
> I'm pulling from master for the new 0.4 content. As long as this is
> in
> a different branch until it's cleaned up, I think we'll be good.
>
It's already pushed into master. I would recommend basing the new release
on 5251bdccebb9a9612f19fa008276ebc5a07ae29c or wait a few days until I
provide few patches.
Thanks,
Kamil
13 years, 8 months
New branch - multihook_tests
by Vojtěch Aschenbrenner
Hiya autoqa friends,
I created a new git branch named 'multihook_tests'. There are some
modified tests which are now able to run with both post-koji-build and
post-bodhi-update hooks. It's first dirty version, but it should be
function (it's tested with a few packages).
13 years, 8 months
AutoQA 0.4.0 update
by Will Woods
So!
We've made some impressive progress on autoqa in recent weeks, and (as
discussed in the QA meeting earlier this week) it'd be a good idea to
push a new package into production.
We agreed in the meeting that current master is ready to be blessed as
0.4.0 - which means the following pending patches will be queued for
0.4.1 or later:
- multihook_tests branch
- ResultsDB support (in jskladan's branch)
- depcheck test (in depcheck branch)
- upgradepath polish patch
I believe jlaska is working on the autoqa-0.4.0-1 build, which should
appear soon.
Thanks for all your hard work, everyone!
-w
13 years, 8 months
Re: [PATCH] Polished upgradepath code - minor fixes.
by Josef Skladanka
It's just that __init__ should be the place to create
instance-variables - nothing more, nothing less.
I don't have any problem with creating these variables
in the run_once, I just made the first change according
to my customs.
Feel free to change it, and apply to master.
Thanks
Joza
----- Original Message -----
From: "Will Woods" <wwoods(a)redhat.com>
To: "List for development discussion of the AutoQA project" <autoqa-devel(a)lists.fedorahosted.org>
Sent: Tuesday, August 31, 2010 6:28:44 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [PATCH] Polished upgradepath code - minor fixes.
This patch looks OK, with one comment:
On Tue, 2010-08-31 at 13:07 +0200, Josef Skladanka wrote:
> - def initialize(self, config):
> - self.config = config_loader(config, self.tmpdir)
> - #URL of logs/results stored on autotest-server
> - self.autotest_url = autoqa.util.make_autotest_url(self.config)
> -
> - def setup(self):
> - pass
> + def __init__(self, *args, **kwargs):
> + super(upgradepath, self).__init__(*args, **kwargs)
> + self.log = []
> + self.envr_list = set()
This is kind of confusing - is there a reason you need to use __init__()
and not initialize(), as suggested by the test template? For example:
def initialize(self, *args, **kwargs):
super(upgradepath, self).initialize(config)
self.log = []
self.envr_list = set()
Even simpler - why not just set self.log and self.envr_list at the top
of run_once()? Then you don't have to worry about running super(...) at
all.
-w
_______________________________________________
autoqa-devel mailing list
autoqa-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/autoqa-devel
13 years, 8 months
[PATCH] be more verbose when autotest scheduling fails
by Kamil Paral
---
autoqa | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/autoqa b/autoqa
index 8fd7dee..e0848ea 100755
--- a/autoqa
+++ b/autoqa
@@ -128,7 +128,7 @@ def maybe_call(cmdlist, dryrun=False, verbose=False):
try:
return call(cmdlist)
except OSError, e:
- print "Command failed: %s" % str(e)
+ print "Error: Command failed: %s\n %s" % (' '.join(cmdlist), e)
return None
def schedule_job(controlfile, required_arch=None, email=None, name=None, dryrun=False, labels=[]):
--
1.7.2.2
13 years, 8 months
[AutoQA] #222: rpmguard: check for dropped arch on multilib updates
by fedora-badges
#222: rpmguard: check for dropped arch on multilib updates
--------------------+-------------------------------------------------------
Reporter: wwoods | Owner:
Type: task | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component: tests | Version: 1.0
Keywords: |
--------------------+-------------------------------------------------------
To properly prevent the `nss-softokn` problem from recurring (see ticket
#201), we need to ensure that new multilib updates do ''not'' mistakenly
drop one of their arches.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/222>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 8 months