[JIRA] (OVIRT-1788) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium

Tuesday, 5 December 2017

This is a multi-part message in MIME format...

------------=_1512491211-28701-144
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

    [
https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jir...
] 

Barak Korren commented on OVIRT-1788:
-------------------------------------

[~gshereme(a)redhat.com] I can make the 1st one for you, making a CentOS container with
firefox installed in it is easy enough, the real challenge for me would be how to make it
run headless and talk to the testing framework and oVirt.

What testing framework do you intend to use? How does it communicate with the browsers it
uses for testing? Does it has built-in support to the situation where the browsers are
running on different containers or hosts then the testing framework (Processes in
different containers typically look to one another as if they are on different hosts)?

...
 new ui_sanity scenario for basic_suite -- need multiple firefoxes and
chromium
 ------------------------------------------------------------------------------

                 Key: OVIRT-1788
                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788
             Project: oVirt - virtualization made easy
          Issue Type: Improvement
          Components: OST
            Reporter: Greg Sheremeta
            Assignee: infra

 I'm writing a suite that does headless UI testing. One goal is to open headless
firefox and actually open the UI, perform a login, make sure things look good, make sure
there are no ui.log errors, etc. I'll also eventually add chromium, which can run
headless now too.
 The suite requires several firefox versions to be installed on the test machine, along
with chromium. There are also some binary components required, geckodriver and
chromedriver. These are not packaged.
 Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62,
etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm
with all of this.
 Where can this rpm live? What is a reliable way to do this? (I know we want to avoid
copr.) 

--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100074)

------------=_1512491211-28701-144
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

<html><body>
<pre>[
https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jir...
]</pre>
<h3>Barak Korren commented on OVIRT-1788:</h3>
<p&gt;[~gshereme(a)redhat.com] I can make the 1st one for you, making a CentOS container
with firefox installed in it is easy enough, the real challenge for me would be how to
make it run headless and talk to the testing framework and oVirt.</p>
<p>What testing framework do you intend to use? How does it communicate with the
browsers it uses for testing? Does it has built-in support to the situation where the
browsers are running on different containers or hosts then the testing framework
(Processes in different containers typically look to one another as if they are on
different hosts)?</p>
<blockquote><h3>new ui_sanity scenario for basic_suite &mdash; need
multiple firefoxes and chromium</h3>
<pre>     Key: OVIRT-1788
     URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1788
 Project: oVirt - virtualization made easy
         Issue Type: Improvement
         Components: OST
Reporter: Greg Sheremeta
Assignee: infra</pre>
<p>I'm writing a suite that does headless UI testing. One goal is to open
headless firefox and actually open the UI, perform a login, make sure things look good,
make sure there are no ui.log errors, etc. I'll also eventually add chromium, which
can run headless now too. The suite requires several firefox versions to be installed on
the test machine, along with chromium. There are also some binary components required,
geckodriver and chromedriver. These are not packaged. Ideally the browsers can be
installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running
the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can
this rpm live? What is a reliable way to do this? (I know we want to avoid
copr.)</p></blockquote>
<p>&mdash; This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100074)</p>

------------=_1512491211-28701-144--

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011