- Infra - oVirt List Archives

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Greg Sheremeta (oVirt JIRA) 11 Mar '18

11 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] Greg Sheremeta updated OST-99: ------------------------------ Description: 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.) ... Update for posterity (Mar 11 2018): we decided in the comments below to use [Selenium Grid|https://www.seleniumhq.org/docs/07_selenium_grid.jsp] and [docker-compose|https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-S…] Since Selenium Grid provides preconfigured containers, we're not maintaining anything other than docker-compose yaml files. No need to worry about packaging browsers ourselves. --- https://gerrit.ovirt.org/#/c/67166 was: 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.) ... Update for posterity (Mar 11 2018): we decided in the comments below to use [Selenium Grid|https://www.seleniumhq.org/docs/07_selenium_grid.jsp] and [docker-compose|https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-S…] Since Selenium Grid provides preconfigured containers, we're not maintaining anything other than docker-compose yaml files. No need to worry about packaging browsers ourselves. > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082)

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Greg Sheremeta (oVirt JIRA) 11 Mar '18

11 Mar '18

This is a multi-part message in MIME format... ------------=_1520772085-26371-157 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] Greg Sheremeta commented on OST-99: ----------------------------------- I have this working and a patch posted -- closing. Thanks for the help everyone! > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082) ------------=_1520772085-26371-157 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ]</pre> <h3>Greg Sheremeta commented on OST-99:</h3> <p>I have this working and a patch posted — closing.</p> <p>Thanks for the help everyone!</p> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OST-99 URL: https://ovirt-jira.atlassian.net/browse/OST-99 Project: oVirt system tests Issue Type: Improvement Reporter: Greg Sheremeta Assignee: infra</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1520772085-26371-157--

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Greg Sheremeta (oVirt JIRA) 11 Mar '18

11 Mar '18

[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] Greg Sheremeta updated OST-99: ------------------------------ Resolution: Done Status: Done (was: In Progress) > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082)

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by Greg Sheremeta (oVirt JIRA) 11 Mar '18

11 Mar '18

This is a multi-part message in MIME format... ------------=_1520771999-12112-110 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] Greg Sheremeta updated OST-99: ------------------------------ Description: 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.) ... Update for posterity (Mar 11 2018): we decided in the comments below to use [Selenium Grid|https://www.seleniumhq.org/docs/07_selenium_grid.jsp] and [docker-compose|https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-S…] Since Selenium Grid provides preconfigured containers, we're not maintaining anything other than docker-compose yaml files. No need to worry about packaging browsers ourselves. was: 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.) > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082) ------------=_1520771999-12112-110 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ]</pre> <h3>Greg Sheremeta updated OST-99:</h3> <pre>Description:</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.</p> <p>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.</p> <p>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.</p> <p>Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p> <p>…</p> <p>Update for posterity (Mar 11 2018): we decided in the comments below to use [Selenium Grid|<a href="https://www.seleniumhq.org/docs/07_selenium_grid.jsp">https://www.seleniumhq.org/docs/07_selenium_grid.jsp</a>] and [docker-compose|<a href="https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-Started-with-Doc…">https://github.com/SeleniumHQ/docker-selenium/wiki/Getting-Started-with-Doc…</a>]. Since Selenium Grid provides preconfigured containers, we're not maintaining anything other than docker-compose yaml files. No need to worry about packaging browsers ourselves.</p> <pre>was:</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.</p> <p>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.</p> <p>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.</p> <p>Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OST-99 URL: https://ovirt-jira.atlassian.net/browse/OST-99 Project: oVirt system tests Issue Type: Improvement Reporter: Greg Sheremeta Assignee: infra</pre></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100082)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1520771999-12112-110--

1 0

[CQ]: 88741, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 11 Mar '18

11 Mar '18

A system test invoked by the "ovirt-4.2" change queue including change 88741,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 88738,2 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 88738,2 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/88741/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/88738/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1181/

1 0

[CQ]: 88581, 4 (ovirt-engine) failed "ovirt-master" system tests, but isn't the failure root cause
by oVirt Jenkins 11 Mar '18

11 Mar '18

A system test invoked by the "ovirt-master" change queue including change 88581,4 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 88620,4 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 88620,4 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/88581/4 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/88620/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6228/

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1352
by jenkins＠jenkins.phx.ovirt.org 11 Mar '18

11 Mar '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision d366bf1404c10c49b1f2ed0fe5a0bd9403edd23f (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f d366bf1404c10c49b1f2ed0fe5a0bd9403edd23f Commit message: "Make headers lowercase for standard-webhook-trigger" > git rev-list --no-walk d366bf1404c10c49b1f2ed0fe5a0bd9403edd23f # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins6923647727206306001.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7 error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7' Build step 'Execute shell' marked build as failure

1 1

[CQ]: 88741, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 10 Mar '18

10 Mar '18

A system test invoked by the "ovirt-4.2" change queue including change 88741,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 88738,2 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 88738,2 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/88741/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/88738/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1176/

1 0

[CQ]: 88739, 2 (ovirt-engine) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 10 Mar '18

10 Mar '18

A system test invoked by the "ovirt-4.2" change queue including change 88739,2 (ovirt-engine) failed. However, this change seems not to be the root cause for this failure. Change 88738,2 (ovirt-engine) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 88738,2 (ovirt-engine) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/88739/2 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/88738/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1175/

1 0

[CQ]: 88738,2 (ovirt-engine) failed "ovirt-4.2" system tests
by oVirt Jenkins 10 Mar '18

10 Mar '18

Change 88738,2 (ovirt-engine) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/88738/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1172/

1 0