• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

SatelliteQE / robottelo / 8839 / 1
37%
master: 37%

Build:
DEFAULT BRANCH: master
Ran 25 Jan 2017 04:00PM UTC
Files 27
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

25 Jan 2017 03:54PM UTC coverage: 71.847%. Remained the same
TOXENV=py27

push

travis-ci

svtkachenko
Decorated UI bookmark tests with run_in_one_thread decorator (#4243)

There's no searchbar on bookmarks page and in order to find specific bookmark the only thing we can do is set `items_per_page` to some huge value before tests execution and revert the value afterwards. The problem here is the fact that with multithreading each thread is playing with global `items_per_page` separately and as soon as one of threads finished execution it reverts value back to 20. That leads to failures as some other thread which is still executing the test suddenly can see only first 20 bookmarks from the list.

Made some investigation and couldn't find any better solution rather than mark the tests as sequential ones. `items_per_page` is a global variable which should not be accessed by multiple threads at the same time.
There's no way to fix the issue on unittests side - with parallel execution all of its methods like setUp/setUpClass/setUpModule are duplicated for each thread.
No way to fix it on py.test side too - found multiple open issues in their repo where people ask to add the ability to execute some actions in 1 thread before executing tests simultaneously and there's no resolution as for now.

So the only way to deal with issue in timely manner i can see is to mark the tests as sequential ones. Bookmark tests are pretty fast as they do not use manifests/hosts provisioning etc, so we shouldn't affect performance much. And imo it's worth it to wait for another minute or two but receive correct results instead of 1-2 mins faster but with 3-5 random failures.
And btw, current UI bookmark search implementation contains check whether RFE BZ for searchbar is closed, so we don't even need to introduce some kind of `if bz_bug_is_open` checks for `@run_in_one_thread` decorator as we will know for sure when the searchbar is finally there.

1544 of 2149 relevant lines covered (71.85%)

0.72 hits per line

Source Files on job 8839.1 (TOXENV=py27)
  • Tree
  • List 0
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Build 8839
  • Travis Job 8839.1
  • 5c5afb24 on github
  • Prev Job for TOXENV=py27 on master (#8830.1)
  • Next Job for TOXENV=py27 on master (#8847.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc