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

SatelliteQE / robottelo / 8839
37%

Build:
DEFAULT BRANCH: master
Ran 25 Jan 2017 04:00PM UTC
Jobs 2
Files 27
Run time 26s
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

pending completion
8839

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.

1546 of 2149 relevant lines covered (71.94%)

1.44 hits per line

Jobs
ID Job ID Ran Files Coverage
1 8839.1 (TOXENV=py27) 25 Jan 2017 04:00PM UTC 0
71.85
Travis Job 8839.1
2 8839.2 (TOXENV=py34) 25 Jan 2017 04:01PM UTC 0
71.8
Travis Job 8839.2
Source Files on build 8839
Detailed source file information is not available for this build.
  • Back to Repo
  • Travis Build #8839
  • 5c5afb24 on github
  • Prev Build on master (#8830)
  • Next Build on master (#8847)
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