BigW Consortium Gitlab

  1. 25 Oct, 2016 3 commits
  2. 19 Oct, 2016 1 commit
  3. 10 Oct, 2016 1 commit
    • Precalculate trending projects · 237c8f66
      Yorick Peterse authored
      This commit introduces a Sidekiq worker that precalculates the list of
      trending projects on a daily basis. The resulting set is stored in a
      database table that is then queried by Project.trending.
      
      This setup means that Unicorn workers no longer _may_ have to calculate
      the list of trending projects. Furthermore it supports filtering without
      any complex caching mechanisms.
      
      The data in the "trending_projects" table is inserted in the same order
      as the project ranking. This means that getting the projects in the
      correct order is simply a matter of:
      
          SELECT projects.*
          FROM projects
          INNER JOIN trending_projects ON trending_projects.project_id = projects.id
          ORDER BY trending_projects.id ASC;
      
      Such a query will only take a few milliseconds at most (as measured on
      GitLab.com), opposed to a few seconds for the query used for calculating
      the project ranks.
      
      The migration in this commit does not require downtime and takes care of
      populating an initial list of trending projects.
  4. 05 Oct, 2016 1 commit
    • Refactor TrendingProjectsFinder to support caching · 154253ca
      Yorick Peterse authored
      == Public Projects
      
      This finder class now _only_ returns public projects. Previously this
      finder would also return private and internal projects. Including these
      projects makes caching data much harder and less efficient. Meanwhile
      including this data isn't very useful as very few users would be
      interested in seeing projects they have access to as trending. That is,
      the feature is more useful when you want to see what _other_ popular
      projects there are.
      
      == Caching
      
      The data returned by TrendingProjectsFinder is now cached for a day
      based on the number of months the data should be restricted to. The
      cache is not flushed explicitly, instead it's rebuilt whenever it
      expires.
      
      == Timings
      
      To measure the impact I changed the finder code to use the last 24
      months instead of the last month. I then executed and measured 10
      requests to the explore page. On the current "master" branch (commit
      88fa5916) this would take an average of
      2.43 seconds. Using the changes of this commit this was reduced to
      around 1.7 seconds.
      
      Fixes gitlab-org/gitlab-ce#22164
  5. 03 Oct, 2016 2 commits
  6. 28 Sep, 2016 2 commits
    • Allow Member.add_user to handle access requesters · ec0061a9
      Rémy Coutable authored
      Changes include:
      
      - Ensure Member.add_user is not called directly when not necessary
      - New GroupMember.add_users_to_group to have the same abstraction level as for Project
      - Refactor Member.add_user to take a source instead of an array of members
      - Fix Rubocop offenses
      - Always use Project#add_user instead of project.team.add_user
      - Factorize users addition as members in Member.add_users_to_source
      - Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects
      - Destroy any requester before adding them as a member
      - Improve the way we handle access requesters in Member.add_user
        Instead of removing the requester and creating a new member,
        we now simply accepts their access request. This way, they will
        receive a "access request granted" email.
      - Fix error that was previously silently ignored
      - Stop raising when access level is invalid in Member, let Rails validation do their work
      Signed-off-by: 's avatarRémy Coutable <remy@rymai.me>
    • New AccessRequestsFinder · 924a6b7d
      Rémy Coutable authored
      Signed-off-by: 's avatarRémy Coutable <remy@rymai.me>
  7. 20 Sep, 2016 1 commit
  8. 09 Sep, 2016 1 commit
  9. 07 Sep, 2016 1 commit
  10. 31 Aug, 2016 1 commit
  11. 19 Aug, 2016 1 commit
  12. 18 Aug, 2016 1 commit
  13. 17 Aug, 2016 1 commit
  14. 15 Aug, 2016 2 commits
  15. 09 Aug, 2016 1 commit
  16. 02 Aug, 2016 1 commit
  17. 01 Aug, 2016 1 commit
  18. 28 Jul, 2016 1 commit
    • Fix the title of the toggle dropdown button · 94e6d51e
      Herminio Torres authored
      Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value.
      
      E.g.
      
      When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title.
      
      Change the implementation of the `link_to` `filter_branches_path`
      
      - Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`.
      
      - Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.
  19. 26 Jul, 2016 1 commit
  20. 19 Jul, 2016 2 commits
  21. 12 Jul, 2016 1 commit
  22. 01 Jul, 2016 1 commit
  23. 16 Jun, 2016 2 commits
  24. 15 Jun, 2016 1 commit
  25. 14 Jun, 2016 1 commit
  26. 03 Jun, 2016 2 commits
  27. 16 May, 2016 2 commits
    • Make upcoming milestone work across projects · 750b2ff0
      Sean McGivern authored
      Before: we took the next milestone due across all projects in the
      search and found issues whose milestone title matched that
      one. Problems:
      
      1. The milestone could be closed.
      2. Different projects have milestones with different schedules.
      3. Different projects have milestones with different titles.
      4. Different projects can have milestones with different schedules, but
         the _same_ title. That means we could show issues from a past
         milestone, or one that's far in the future.
      
      After: gather the ID of the next milestone on each project we're looking
      at, and find issues with those milestone IDs. Problems:
      
      1. For a lot of projects, this can return a lot of IDs.
      2. The SQL query has to be different between Postgres and MySQL, because
         MySQL is much more lenient with HAVING: as well as the columns
         appearing in GROUP BY or in aggregate clauses, MySQL allows them to
         appear in the SELECT list (un-aggregated).
    • Tidy up IssuesFinder specs · 91480e5e
      Sean McGivern authored
      - Don't do setup in spec bodies.
      - Don't `describe` a symbol.
      - Don't use 'should'.
  28. 13 Apr, 2016 1 commit
  29. 21 Mar, 2016 3 commits