BigW Consortium Gitlab

  1. 03 Apr, 2017 1 commit
  2. 24 Feb, 2017 1 commit
  3. 01 Feb, 2017 1 commit
  4. 26 Jan, 2017 1 commit
  5. 17 Jan, 2017 2 commits
  6. 08 Dec, 2016 1 commit
  7. 29 Nov, 2016 1 commit
  8. 21 Nov, 2016 2 commits
  9. 20 Sep, 2016 1 commit
    • Implement a second round of review comments from @DouweM. · 918e589c
      Timothy Andrew authored
      - Don't use `TableReferences` - using `.arel_table` is shorter!
      - Move some database-related code to `Gitlab::Database`
      - Remove the `MergeRequest#issues_closed` and
        `Issue#closed_by_merge_requests`  associations. They were either
        shadowing or were too similar to existing methods. They are not being
        used anywhere, so it's better to remove them to reduce confusion.
      - Use Rails 3-style validations
      - Index for `MergeRequest::Metrics#first_deployed_to_production_at`
      - Only include `CycleAnalyticsHelpers::TestGeneration` for specs that
        need it.
      - Other minor refactorings.
  10. 07 Sep, 2016 3 commits
    • Consolidate all cycle analytics helper methods. · 0a767f7b
      Timothy Andrew authored
      1. Move the test generation to `CycleAnalyticsHelpers::TestGeneration`
      
      2. Move all helper methods (previously placed in each individual spec
         file) to `CycleAnalyticsHelpers`
    • Test the `production` cycle analytics phase. · de483c68
      Timothy Andrew authored
      Add a `before_end_fn` option to the code that generates cycle analytics
      specs. `before_end_fn` is called before the end conditions are. Used for
      data setup that needs to be called after the start conditions and before
      the end conditions.
    • Test the `staging` cycle analytics phase. · dd112ef1
      Timothy Andrew authored
      Remove overlap from the "start + end" durations in the happy test
      case. For the `staging` phase, the end time is the _first_ deployment
      that happens after the MR merge.
      
      If we have 5 MRs where the `start_time`s (merge time) are the
      same, and all the `end_time`s (deploy to production) a few days from
      now, only the earliest deploy will get picked up, because that
      consitutes a deploy for _all_ the MRs.
      
      We fix this by removing overlap. Every `start_time` is now generated to
      be _after_ the preceding `end_time`.