BigW Consortium Gitlab

  1. 17 Jan, 2017 11 commits
  2. 29 Nov, 2016 1 commit
  3. 21 Nov, 2016 2 commits
  4. 17 Nov, 2016 2 commits
  5. 13 Oct, 2016 1 commit
  6. 12 Oct, 2016 1 commit
  7. 20 Sep, 2016 5 commits
    • 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.
    • Implement (some) comments from @DouweM's review. · 71d4bf72
      Timothy Andrew authored
      - Move things common to `Issue` and `MergeRequest` into `Issuable`
      - Move more database-specific functions into `Gitlab::Database`
      - Indentation changes and other minor refactorings.
    • Implement review comments from @yorickpeterse · 8957293d
      Timothy Andrew authored
      1. Change multiple updates to a single `update_all`
      
      2. Use cascading deletes
      
      3. Extract an average function for the database median.
      
      4. Move database median to `lib/gitlab/database`
      
      5. Use `delete_all` instead of `destroy_all`
      
      6. Minor refactoring
    • Implement a database median strategy for MySQL. · 4ff8d5d2
      Timothy Andrew authored
      1. Dispatch between the two strategies automatically based on the
         current database type.
      
      2. The MySQL version needs to run multiple statements, so the
         `cycle_analytics` model is modified to support this.
    • CycleAnalytics operates on merge requests that have been deployed. · cebfe053
      Timothy Andrew authored
      1. Look for merge requests (and issues that they close) that have been
         deployed to production in the last X days (where X is given by the
         `from` parameter).
      
      2. Cycle analytics queries only operate on this fitered set of merge
         requests and issues.
  8. 19 Sep, 2016 1 commit
  9. 17 Sep, 2016 2 commits
  10. 15 Sep, 2016 1 commit
    • Improve performance of the cycle analytics page. · ba25e2f1
      Timothy Andrew authored
      1. These changes bring down page load time for 100 issues from more than
         a minute to about 1.5 seconds.
      
      2. This entire commit is composed of these types of performance
         enhancements:
      
           - Cache relevant data in `IssueMetrics` wherever possible.
           - Cache relevant data in `MergeRequestMetrics` wherever possible.
           - Preload metrics
      
      3. Given these improvements, we now only need to make 4 SQL calls:
      
          - Load all issues
          - Load all merge requests
          - Load all metrics for the issues
          - Load all metrics for the merge requests
      
      4. A list of all the data points that are now being pre-calculated:
      
          a. The first time an issue is mentioned in a commit
      
            - In `GitPushService`, find all issues mentioned by the given commit
              using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
              flag for each of them.
      
            - There seems to be a (pre-existing) bug here - files (and
              therefore commits) created using the Web CI don't have
              cross-references created, and issues are not closed even when
              the commit title is "Fixes #xx".
      
          b. The first time a merge request is deployed to production
      
            When a `Deployment` is created, find all merge requests that
            were merged in before the deployment, and set the
            `first_deployed_to_production_at` flag for each of them.
      
          c. The start / end time for a merge request pipeline
      
            Hook into the `Pipeline` state machine. When the `status` moves to
            `running`, find the merge requests whose tip commit matches the
            pipeline, and record the `latest_build_started_at` time for each
            of them. When the `status` moves to `success`, record the
            `latest_build_finished_at` time.
      
          d. The merge requests that close an issue
      
            - This was a big cause of the performance problems we were having
              with Cycle Analytics. We need to use `ReferenceExtractor` to make
              this calculation, which is slow when we have to run it on a large
              number of merge requests.
      
            - When a merge request is created, updated, or refreshed, find the
              issues it closes, and create an instance of
              `MergeRequestsClosingIssues`, which acts as a join model between
              merge requests and issues.
      
            - If a `MergeRequestsClosingIssues` instance links a merge request
              and an issue, that issue closes that merge request.
      
      5. The `Queries` module was changed into a class, so we can cache the
         results of `issues` and `merge_requests_closing_issues` across
         various cycle analytics stages.
      
      6. The code added in this commit is untested. Tests will be added in the
         next commit.
  11. 08 Sep, 2016 1 commit
  12. 02 Sep, 2016 1 commit
    • Tweak cycle analytics query to match the current requirements. · 0910868d
      Timothy Andrew authored
      - The `review` phase ends when a MR is merged, not "merged OR closed".
      - The `code` phase starts when a MR is first mentioned in a commit, and
        ends when a merge request closing the issue is created.
      - The `plan` phase ends when the issue first mentioned in a commit.
      
      ---
      
      - Fix the `median` function so it sorts the incoming data points.
      - A data point where `end_time` is prior to `start_time` is invalid.
  13. 26 Aug, 2016 9 commits