BigW Consortium Gitlab

  1. 11 Mar, 2016 1 commit
  2. 07 Mar, 2016 1 commit
  3. 05 Mar, 2016 1 commit
  4. 02 Mar, 2016 1 commit
  5. 19 Feb, 2016 2 commits
  6. 17 Feb, 2016 1 commit
  7. 16 Feb, 2016 1 commit
  8. 15 Feb, 2016 1 commit
    • Fix the "x of y" displayed at the top of Issuables' sidebar · 54613b6a
      Rémy Coutable authored
      1. We now display the index of the current issuable among all its project's
      issuables, of the same type and with the same state.
      2. Also, refactored a bit the Issuable helpers into a new IssuablesHelper
      module.
      3. Added acceptance specs for the sidebar counter.
  9. 11 Feb, 2016 1 commit
    • Add new data to project in push, issue, merge-request and note webhooks data · b123171d
      Kirill Zaitsev authored
      - Add `avatar_url`, `description`, `git_ssh_url`, `git_http_url`,
        `path_with_namespace` and `default_branch` in `project` in push, issue,
        merge-request and note webhooks data
      - Deprecate the `ssh_url` in favor of `git_ssh_url` and `http_url` in
        favor of `git_http_url` in `project` for push, issue, merge-request and
        note webhooks data
      - Deprecate the `repository` key in push, issue, merge-request and
        note webhooks data, use `project` instead
  10. 10 Feb, 2016 1 commit
  11. 22 Jan, 2016 1 commit
  12. 20 Jan, 2016 1 commit
  13. 09 Jan, 2016 1 commit
  14. 07 Jan, 2016 1 commit
    • Sort by ID when sorting using "Recently created" · 9dacc3bc
      Yorick Peterse authored
      Sorting by "id" has the same effect as sorting by created_at while
      performing far better and without the need of an extra index (in case
      one wanted to speed up sorting by "created_at").
      
      Sorting by "Recently updated" still uses the physical "updated_at"
      column as there's no way to use the "id" column for this instead.
  15. 06 Jan, 2016 1 commit
  16. 28 Dec, 2015 1 commit
  17. 24 Dec, 2015 2 commits
  18. 23 Dec, 2015 3 commits
  19. 21 Dec, 2015 1 commit
  20. 16 Dec, 2015 1 commit
  21. 15 Dec, 2015 2 commits
  22. 11 Dec, 2015 3 commits
  23. 01 Dec, 2015 2 commits
  24. 30 Nov, 2015 2 commits
  25. 26 Nov, 2015 1 commit
  26. 21 Nov, 2015 1 commit
  27. 20 Nov, 2015 3 commits
  28. 19 Nov, 2015 1 commit
    • Use a JOIN in IssuableFinder#by_project · 8591cc02
      Yorick Peterse authored
      When using IssuableFinder/IssuesFinder to find issues for multiple
      projects it's more efficient to use a JOIN + a "WHERE project_id IN"
      condition opposed to running a sub-query.
      
      This change means that when finding issues without labels we're now
      using the following SQL:
      
          SELECT issues.*
          FROM issues
          JOIN projects ON projects.id = issues.project_id
      
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE (
              projects.id IN (...)
              OR projects.visibility_level IN (20, 10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      instead of:
      
          SELECT issues.*
          FROM issues
          LEFT JOIN label_links ON label_links.target_type = 'Issue'
                                AND label_links.target_id  = issues.id
      
          WHERE issues.project_id IN (
              SELECT id
              FROM projects
              WHERE id IN (...)
              OR visibility_level IN (20,10)
          )
          AND issues.state IN ('opened','reopened')
          AND label_links.id IS NULL
          ORDER BY issues.id DESC;
      
      The big benefit here is that in the last case PostgreSQL can't properly
      use all available indexes. In particular it ends up performing a
      sequence scan on the "label_links" table (processing around 290 000
      rows). The new query is roughly 2x as fast as the old query.
  29. 18 Nov, 2015 1 commit