Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • beat.core beat.core
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 14
    • Issues 14
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • beatbeat
  • beat.corebeat.core
  • Issues
  • #56
Closed
Open
Issue created May 04, 2018 by Jaden DIEFENBAUGH@jdiefenbaughContributor

Docker timer tests rely on having adequate CI resources

Sometimes docker timing tests will fail when the tests go too slowly. These tests rely on a hard-coded number of seconds/milliseconds with numbers that are reasonable to assume on one's own machine but obviously aren't designed for a CI (just see the docker tests.

Some of these tests can just be changed. For example, the test_images_cache tests are actually relative tests - you just want to be sure that doing something a second time is faster than the first time. I believe that the CI performance would be consistent across each of these tests (which shouldn't last for more than a couple seconds).

There's other ones though, like the timeout tests. Not sure what to do with those.

This doesn't unconditionally make the CI fail since rerunning the job usually fixes it.

Assignee
Assign to
Time tracking