1. 17 Nov, 2016 1 commit
  2. 04 Nov, 2016 1 commit
  3. 03 Nov, 2016 1 commit
  4. 28 Oct, 2016 1 commit
  5. 24 Oct, 2016 1 commit
  6. 20 Oct, 2016 3 commits
  7. 19 Oct, 2016 1 commit
  8. 18 Oct, 2016 3 commits
  9. 14 Oct, 2016 5 commits
  10. 13 Oct, 2016 1 commit
    • Sean McGivern's avatar
      Allow setting content for resolutions · 0483c1e6acbc
      Sean McGivern authored
      When reading conflicts:
      1. Add a `type` field. `text` works as before, and has `sections`;
         `text-editor` is a file with ambiguous conflict markers that can only
         be resolved in an editor.
      2. Add a `content_path` field pointing to a JSON representation of the
         file's content for a single file.
      3. Hitting `content_path` returns a similar datastructure to the `file`,
         but without the `content_path` and `sections` fields, and with a
         `content` field containing the full contents of the file (with
         conflict markers).
      When writing conflicts:
      1. Instead of `sections` being at the top level, they are now in a
         `files` array. This matches the read format better.
      2. The `files` array contains file hashes, each of which must contain:
         a. `new_path`
         b. `old_path`
         c. EITHER `sections` (which works as before) or `content` (with the
            full content of the resolved file).
  11. 06 Oct, 2016 1 commit
  12. 03 Oct, 2016 2 commits
  13. 27 Sep, 2016 1 commit
  14. 21 Sep, 2016 2 commits
  15. 20 Sep, 2016 8 commits
  16. 19 Sep, 2016 4 commits
    • Lin Jen-Shin's avatar
      Show all pipelines from all merge_request_diffs: · 35c7853e0d71
      Lin Jen-Shin authored
      This way we could also show pipelines from commits which
      were discarded due to a force push.
    • Kamil Trzcinski's avatar
      Cleanup changes · 2067717dcef8
      Kamil Trzcinski authored
    • Kamil Trzcinski's avatar
      Add support for dynamic environments · 10455c10ebdd
      Kamil Trzcinski authored
      Environments that can have a URL with predefined CI variables.
    • Timothy Andrew's avatar
      Test all cycle analytics pre-calculation code. · fbf82d1d74ae
      Timothy Andrew authored
      All the code that pre-calculates metrics for use in the cycle analytics
      - Ci::Pipeline -> build start/finish
      - Ci::Pipeline#merge_requests
      - Issue -> record default metrics after save
      - MergeRequest -> record default metrics after save
      - Deployment -> Update "first_deployed_to_production_at" for MR metrics
      - Git Push -> Update "first commit mention" for issue metrics
      - Merge request create/update/refresh -> Update "merge requests closing issues"
  17. 16 Sep, 2016 1 commit
  18. 15 Sep, 2016 1 commit
    • Timothy Andrew's avatar
      Improve performance of the cycle analytics page. · 52e536c75ee6
      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
           - 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.
  19. 13 Sep, 2016 2 commits