On 1.8.2018 00:51, Adam Williamson wrote:
On Wed, 2018-08-01 at 00:13 +0200, Miro Hrončok wrote:
Hi,
could somebody please test upgrade from fully upgraded Workstation 28 to
29? I have a suspicion that it will be blocked by [0], yet I lack disk
space to try it.
Thanks.
[0] https
On Wed, 2018-08-01 at 00:13 +0200, Miro Hrončok wrote:
> Hi,
>
> could somebody please test upgrade from fully upgraded Workstation 28 to
> 29? I have a suspicion that it will be blocked by [0], yet I lack disk
> space to try it.
>
> Thanks.
>
> [0] https://bugzilla
Hi,
could somebody please test upgrade from fully upgraded Workstation 28 to
29? I have a suspicion that it will be blocked by [0], yet I lack disk
space to try it.
Thanks.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1605613
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
On 23.4.2018 20:06, Adam Williamson wrote:
I did ask in #fedora-ci on IRC if anyone could answer the question for
you, sorry I didn't check to see if anyone had followed up. It's not
*wrong* exactly, but the folks here are not mostly the folks
responsible for the 'Fedora CI' stuff, this list is o
On Sat, 2018-04-21 at 17:07 +0200, Miro Hrončok wrote:
> On 17.4.2018 22:45, Miro Hrončok wrote:
> > I'm trying to follow the following guide:
> >
> > https://fedoraproject.org/wiki/CI/Tests#Wrapping
> >
> > ...
> >
> > What piece am I missing?
>
> Is this a wrong place ask?
I did ask in #fedo
On 21.4.2018 18:13, Matthew Miller wrote:
On Sat, Apr 21, 2018 at 05:07:16PM +0200, Miro Hrončok wrote:
I'm trying to follow the following guide:
https://fedoraproject.org/wiki/CI/Tests#Wrapping
What piece am I missing?
Is this a wrong place ask?
Maybe try c...@lists.fedoraproject.org?
Than
On Sat, Apr 21, 2018 at 05:07:16PM +0200, Miro Hrončok wrote:
> >I'm trying to follow the following guide:
> >https://fedoraproject.org/wiki/CI/Tests#Wrapping
> >What piece am I missing?
> Is this a wrong place ask?
Maybe try c...@lists.fedoraproject.org?
--
Matthew Miller
Fedora Project Leade
On 17.4.2018 22:45, Miro Hrončok wrote:
I'm trying to follow the following guide:
https://fedoraproject.org/wiki/CI/Tests#Wrapping
...
What piece am I missing?
Is this a wrong place ask?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
qa
I'm trying to follow the following guide:
https://fedoraproject.org/wiki/CI/Tests#Wrapping
Let's say I've done the following:
$ fedpkgclone gzip
$ cd gzip/tests/
Now I want to run the tests in Docker. The guide says:
> Try running this example test against an Atomic Host or
Hi folks! Another note for anyone paying attention to openQA test
results.
Since 2017-08-09 there's been kind of a flood of failures caused by
'typing errors' - that is, when the test runner is trying to type a
string into the test VM and it doesn't get through correctly (u
x27;build' value for these
tests) certainly don't. I've got a PR in progress upstream to allow us
to sort these differently, and that should get changed soon.
About half way through last week I implemented a change which means any
failed test is automatically retried; this cut d
nd compare the timestamp. These race conditions
> > occur surprisingly often once you start executing hundreds/thousands
> > tasks a day.
> >
> > But if this is easier done in the scheduler, I think that's totally fine.
>
> During test execution, we can only really
itions
> occur surprisingly often once you start executing hundreds/thousands
> tasks a day.
>
> But if this is easier done in the scheduler, I think that's totally fine.
During test execution, we can only really type stuff into the console.
We try to keep the amount of typing-into-co
> 2017-03-01 18:04 GMT+01:00 Adam Williamson :
> > I'm not so sure it's really necessary, and doing it is actually tricky
> > for openQA. Only the openQA job itself knows what packages it actually
> > tested, and it doesn't have an easy way to get the associated
> > timestamp. The scheduler could e
the job completed, but that will never
> be 100% reliable, because the job actually goes and does the download
> somewhere in between those two times.
This problem is not exclusive to openqa, it affects all tasks that test bodhi
updates and download the included rpms (there's always a
2017-03-01 18:04 GMT+01:00 Adam Williamson :
> I'm not so sure it's really necessary, and doing it is actually tricky
> for openQA. Only the openQA job itself knows what packages it actually
> tested, and it doesn't have an easy way to get the associated
> timestamp. The scheduler could easily get
On Wed, 2017-03-01 at 11:18 -0500, Kamil Paral wrote:
> So my first thought was to recommend you to also publish just
> type=koji_build results and finish this transition. But then I
> realized that's wrong. OpenQA operates completely different than the
> aforementioned tasks do. We operate on buil
> Hi folks!
>
> I am currently rolling out some changes to the Fedora openQA deployment
> which enable a new testing workflow. From now on, a subset of openQA
> tests should be run automatically on every critpath update, both on
> initial submission and on any edit of the update.
>
> For the next
ration.
The tests that are run are most of the tests that, on the 'compose
test' workflow, get run on the Server DVD and Workstation Live images
after installation. Between them they do a decent job of covering basic
system functionality. They also cover FreeIPA server and client set
On Fri, 3 Feb 2017 17:05:04 -0500 (EST)
Kamil Paral wrote:
> I spent a bit of time fixing minor issues in our test suite and
> makefiles and would like to do the following further changes across
> all our taskotron projects:
>
> 1. run the test suite while inside virtualenv with
stuff that needs to be compiled
>
> Sounds reasonable, Kamil? Others?
>
>
> I went back and forth on this. I thought it would be a really simple
> change, and as usual, it seems more pain than gain. So, I went forward with
> this:
> 1. add tox.ini to projects to allow simple tes
o, I went forward with this:
1. add tox.ini to projects to allow simple test suite execution with `pytest`
(non-controversial)
2. configure tox.ini to print out test coverage (non-controversial)
3. remove --system-site-packages from all places (readme, makefile) for those
projects, that
system, in order to "skip" the
stuff that needs to be compiled
Sounds reasonable, Kamil? Others?
Joza
On Mon, Feb 6, 2017 at 2:11 PM, Kamil Paral wrote:
>
> 3. use a separate virtualenv when running under `make test`, without
> --system-site-packages if possible, and ensu
> > 3. use a separate virtualenv when running under `make test`, without
> > --system-site-packages if possible, and ensure up-to-date deps are always
> > installed, to eliminate any differences that can occur on different setups
>
> > The only problem I see here, i
ifferent results on
> different setups. That's exactly what I'm trying to eliminate (or at least
> reduce). E.g. https://phab.qa.fedoraproject.org/D where I can run the
> test suite from makefile and you can't, and it's quite difficult to figure
> out why.
>
&g
> On Fri, Feb 3, 2017 at 11:05 PM, Kamil Paral < kpa...@redhat.com > wrote:
> > I spent a bit of time fixing minor issues in our test suite and makefiles
> > and
> > would like to do the following further changes across all our taskotron
> > projects:
>
&g
On Fri, Feb 3, 2017 at 11:05 PM, Kamil Paral wrote:
> I spent a bit of time fixing minor issues in our test suite and makefiles
> and would like to do the following further changes across all our taskotron
> projects:
>
> 1. run the test suite while inside virtualenv with simple `
I spent a bit of time fixing minor issues in our test suite and makefiles and
would like to do the following further changes across all our taskotron
projects:
1. run the test suite while inside virtualenv with simple `pytest` command
2. run the test suite outside of virtualenv with `make test
of all those 500s on login).
> >
> > My goal has been to set up the migration so that there's no account
> > fiddling needed to use the new auth system. Things are working in my
> > testing but I'd like to see more people test out the new auth method
> > b
- Original Message -
> From: "Tim Flink"
> To: qa-devel@lists.fedoraproject.org
> Sent: Wednesday, December 14, 2016 4:56:11 PM
> Subject: Re: Please Test Staging Phabricator
>
> On Wed, 14 Dec 2016 04:09:24 -0500 (EST)
> Kamil Paral wrote:
>
> >
On Wed, 14 Dec 2016 04:09:24 -0500 (EST)
Kamil Paral wrote:
> > After a bunch more fiddling, I think that auth is working correctly
> > now. I've also removed the monikra.me stuff for now and auth will
> > work directly against Fedora's auth systems.
>
> I can now log in :-)
>
> The only slig
> After a bunch more fiddling, I think that auth is working correctly
> now. I've also removed the monikra.me stuff for now and auth will work
> directly against Fedora's auth systems.
I can now log in :-)
The only slight problem I encountered is that I didn't know how to reach my
profile, and t
for logging into our phabricator instance (that should
>> also get rid of all those 500s on login).
>>
>> My goal has been to set up the migration so that there's no account
>> fiddling needed to use the new auth system. Things are working in my
>> testing but I'd l
so that there's no account
> fiddling needed to use the new auth system. Things are working in my
> testing but I'd like to see more people test out the new auth method
> before deploying all of this to production.
>
> If you have the time, please try logging in to
&g
> > For a start Ipsilon tells me it's some entirely foreign third-party
> > domain - 'monikra.me' - that wants access to all my personal
> > information, which is a bit unsettling. I went ahead and let it have
> > it (For Science!) and got:
>
> FWIW, monikra.me is a service that puiterwijk made fo
On Wed, 07 Dec 2016 08:24:46 -0800
Adam Williamson wrote:
> For a start Ipsilon tells me it's some entirely foreign third-party
> domain - 'monikra.me' - that wants access to all my personal
> information, which is a bit unsettling. I went ahead and let it have
> it (For Science!) and got:
FWI
hod for logging into our phabricator instance (that should
>> also get rid of all those 500s on login).
>>
>> My goal has been to set up the migration so that there's no account
>> fiddling needed to use the new auth system. Things are working in my
>> testing but
so that there's no account
> fiddling needed to use the new auth system. Things are working in my
> testing but I'd like to see more people test out the new auth method
> before deploying all of this to production.
>
> If you have the time, please try logging in to
&g
hings are working in my
testing but I'd like to see more people test out the new auth method
before deploying all of this to production.
If you have the time, please try logging in to
https://phab.qa.stg.fedoraproject.org/
I've seen some errors from ipsilon about "Transaction exp
#494: F25 Atomic Test Day
--+---
Reporter: jasonbrooks | Owner: tflink
Type: task | Status: new
Priority: major| Milestone: Fedora 25
Component: Test Day |Version:
Resolution
#494: F25 Atomic Test Day
--+
Reporter: jasonbrooks | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 25
Component: Blocker bug
please ignore
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Please note I've bumped the requirements for mock in libtaskotron and removed
some workarounds we had for bugs in the older version. Please make sure to run
$ git pull
$ pip install -r requirements.txt
otherwise the test suite might not pass for you the next time you run it and
the error
Hey folks!
I got my experimental tool for running anaconda's 'kickstart-tests'
tests in openQA to the point where I think it makes sense to decide
whether or not to go any further with it, and sent a mail to anaconda-
devel-list to discuss that. If folks want to take a look and chime in,
that'd be
Hi folks!
So those of you who watch the openQA results might have noticed that
for the last month or so, there have been lots of problems with the
'chained' tests - the _base_ tests that run for various of the media
after default_install has been run, and use a hard disk snapshot
uploaded by defau
#480: Fedora 24 Translation (L10n) Test Day
---+
Reporter: anipeter | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 24
Component: Test Day |Version:
Resolution
#480: Fedora 24 Translation (L10n) Test Day
---+
Reporter: anipeter | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 24
Component: Test Day |Version:
Resolution
#480: Fedora 24 Translation (L10n) Test Day
---+
Reporter: anipeter | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 23
Component: Test Day |Version:
Resolution
#480: Fedora 24 Translation (L10n) Test Day
--+
Reporter: anipeter | Owner: tflink
Type: task | Status: new
Priority: major | Milestone: Fedora 23
Hi, folks. I know this is interesting to me, so it may be to you.
Pungi4 test / example composes can be found here:
https://kojipkgs.fedoraproject.org/compose/rawhide/
so you can see the various new metadata it produces.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter
#477: Proposed Test Day - NetworkManager (2015-08-20)
---+---
Reporter: lkundrak | Owner: jskladan
Type: task | Status: new
Priority: major | Milestone: Fedora 23
Component: Test Day |Version:
Resolution
#477: Proposed Test Day - NetworkManager (2015-08-20)
-+---
Reporter: lkundrak| Owner: jskladan
Type: task| Status: new
Priority: major | Milestone: Fedora 23
#477: Proposed Test Day - NetworkManager (2015-08-20)
+
Reporter: lkundrak| Owner: jskladan
Type: task| Status: new
Priority: major | Milestone: Fedora 23
#473: Fedora 23 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone: Fedora 23
Component: Test Day |Version:
Resolution
#473: Fedora 23 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone: Fedora 23
Component: Test Day |Version:
Resolution
#473: Fedora 23 Translation (L10n) Test Day
--+
Reporter: anipeter | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone: Fedora 23
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: pschindl
Type: task | Status: closed
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution: fixed
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: pschindl
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: pschindl
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: pschindl
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: pschindl
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution
#468: Fedora 22 Translation (L10n) Test Day
---+---
Reporter: anipeter | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
Component: Test Day |Version:
Resolution
#468: Fedora 22 Translation (L10n) Test Day
--+
Reporter: anipeter | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone: Fedora 22
#443: Better format for test compose (TC) and release candidate (RC) requests
-+-
Reporter: jreznik | Owner: adamwill
Type: enhancement | Status: new
Priority: major
#452: Proposed Test Day - Jenkins
---+---
Reporter: msrb | Owner: pschindl
Type: task | Status: new
Priority: major | Milestone: Fedora 21
Component: Test Day |Version:
Resolution:| Keywords
#452: Proposed Test Day - Jenkins
---+---
Reporter: msrb | Owner: pschindl
Type: task | Status: new
Priority: major | Milestone: Fedora 21
Component: Test Day |Version:
Resolution:| Keywords
#452: Proposed Test Day - Jenkins
---+---
Reporter: msrb | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 21
Component: Test Day |Version:
Resolution:| Keywords:
Blocked By
#452: Proposed Test Day - Jenkins
--+--
Reporter: msrb | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Test Day | Version:
Keywords:| Blocked By:
Blocking
#443: Better format for test compose (TC) and release candidate (RC) requests
-+---
Reporter: jreznik | Owner: adamwill
Type: enhancement | Status: new
Priority: major
an
> do.
My main motivation is to give more clarity to emails in this mailing list,
because the word 'test' is really overloaded with meaning in our field of work.
I think that if we start calling taskotron-runnable tasks 'checks', and use
'tests' only for
lity and combinatorial errors that
automated testing will blithely ignore (because it didn't occur to the
developers to test it that way).
Cheers,
Nick.
- --
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane
Testing Solutions Team Lead
Beaker Dev
, so that
> our users are not confused. Can somebody (probably Tim) clarify what
> should we call a 'check' and what should we call a 'test'? Do I
> understand correctly that 'checks' are anything provided by the users
> (the scripts), and 'tests/testing'
#443: Better format for test compose (TC) and release candidate (RC) requests
-+---
Reporter: jreznik | Owner: adamwill
Type: enhancement | Status: new
Priority: major
#443: Better format for test compose (TC) and release candidate (RC) requests
+
Reporter: jreznik | Owner:
Type: enhancement | Status: new
Priority: major
uld we call a 'check' and
what should we call a 'test'? Do I understand correctly that 'checks' are
anything provided by the users (the scripts), and 'tests/testing' will be used
mainly for denoting unit/functional tests?
At the moment, I'm work
I was asked to forward this to qa-devel. The tickets are already migrated, but
I at least responded to Jan Pazdziora that FAS support should come to Phab soon.
- Forwarded Message -
From: "Jan Pazdziora"
To: "Adam Williamson"
Cc: qa-devel@lists.fedoraproject.org
Sent: Tuesday, January 2
#264: Run eclipse test suite for new eclipse koji builds
+
Reporter: jlaska | Owner:
Type: task| Status: closed
Priority: minor | Milestone: Future test cases
Component: tests | Resolution: wontfix
Keywords
#263: Run kvm-autotest test suite for new virt* koji builds
+
Reporter: jlaska | Owner:
Type: task| Status: closed
Priority: minor | Milestone: Future test cases
Component: tests | Resolution: wontfix
#118: New test proposal: Python debugability
+
Reporter: kparal | Owner:
Type: task| Status: closed
Priority: minor | Milestone: Future test cases
Component: tests | Resolution: wontfix
Keywords
#118: New test proposal: Python debugability
+
Reporter: kparal | Owner:
Type: task| Status: closed
Priority: minor | Milestone: Future test cases
Component: tests | Resolution: wontfix
Keywords
#31: Test for unowned directories
-+
Reporter: dgregor | Owner:
Type: task | Status: closed
Priority: minor| Milestone: Future test cases
Component: tests| Resolution: wontfix
Keywords
#190: Test idea - ABI compatibility check
-+
Reporter: jlaska | Owner:
Type: enhancement | Status: closed
Priority: minor| Milestone: Future test cases
Component: tests| Resolution: wontfix
#274: systemd unit files test
+
Reporter: kparal | Owner:
Type: task| Status: closed
Priority: major | Milestone: Future test cases
Component: tests | Resolution: wontfix
Keywords: | Blocked By
#197: New test: "See also" validity in man pages
+
Reporter: kparal | Owner:
Type: task| Status: closed
Priority: major | Milestone: Future test cases
Component: tests | Resolution: wontfix
#447: Test if updated package version can be installed over the proposed version
+---
Reporter: kparal | Owner:
Type: task| Status: closed
Priority: minor | Milestone: Future tasks
Component: tests | Resolution
#229: Create per-update file conflicts test
-+
Reporter: jlaska | Owner:
Type: enhancement | Status: closed
Priority: major| Milestone: Future test cases
Component: tests| Resolution: wontfix
#447: Test if updated package version can be installed over the proposed version
+---
Reporter: kparal | Owner:
Type: task| Status: new
Priority: minor | Milestone: Future tasks
Component: tests | Resolution:
Keywords
#447: Test if updated package version can be installed over the proposed version
-+--
Reporter: kparal | Owner:
Type: task| Status: new
Priority: minor | Milestone: Future tasks
Component: tests | Keywords:
Blocked
#432: Test day results app should be more navigable: create an event, export
results, view all events
-+--
Reporter: adamwill| Owner: jskladan
Type: enhancement | Status: closed
Priority
#432: Test day results app should be more navigable: create an event, export
results, view all events
-+--
Reporter: adamwill| Owner: jskladan
Type: enhancement | Status: new
Priority: major
#432: Test day results app should be more navigable: create an event, export
results, view all events
-+--
Reporter: adamwill| Owner: jskladan
Type: enhancement | Status: new
Priority: major
#432: Test day results app should be more navigable: create an event, export
results, view all events
-+--
Reporter: adamwill| Owner: jskladan
Type: enhancement | Status: new
Priority: major
#438: repoclosure test is failing due to change in behavior upstream
+--
Reporter: tflink | Owner:
Type: defect | Status: closed
Priority: major | Milestone: Package Update Acceptance Test Plan
#438: repoclosure test is failing due to change in behavior upstream
+--
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component
#438: repoclosure test is failing due to change in behavior upstream
+--
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component
#438: repoclosure test is failing due to change in behavior upstream
+--
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component
#438: repoclosure test is failing due to change in behavior upstream
-+-
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: Package Update Acceptance Test Plan
Component
#362: Test day Request for 6/6/13
---+
Reporter: dpal | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone:
Component: Test Day |Version:
Resolution:| Keywords:
Blocked By
#362: Test day Request for 6/6/13
---+
Reporter: dpal | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone:
Component: Test Day |Version:
Resolution:| Keywords:
Blocked By
#362: Test day Request for 6/6/13
--+-
Reporter: dpal | Owner: tflink
Type: defect| Status: new
Priority: major | Milestone:
Component: Blocker bug tracker
100 matches
Mail list logo
