Skip to content
Snippets Groups Projects
  1. Aug 01, 2018
    • Zeger-Jan van de Weg's avatar
      Add repository languages for projects · 79a5d768
      Zeger-Jan van de Weg authored
      Our friends at GitHub show the programming languages for a long time,
      and inspired by that this commit means to create about the same
      functionality.
      
      Language detection is done through Linguist, as before, where the
      difference is that we cache the result in the database. Also, Gitaly can
      incrementaly scan a repository. This is done through a shell out, which
      creates overhead of about 3s each run. For now this won't be improved.
      
      Scans are triggered by pushed to the default branch, usually `master`.
      However, one exception to this rule the charts page. If we're requesting
      this expensive data anyway, we just cache it in the database.
      
      Edge cases where there is no repository, or its empty are caught in the
      Repository model. This makes use of Redis caching, which is probably
      already loaded.
      
      The added model is called RepositoryLanguage, which will make it harder
      if/when GitLab supports multiple repositories per project. However, for
      now I think this shouldn't be a concern. Also, Language could be
      confused with the i18n languages and felt like the current name was
      suiteable too.
      
      Design of the Project#Show page is done with help from @dimitrieh. This
      change is not visible to the end user unless detections are done.
      Unverified
      79a5d768
  2. Jul 31, 2018
  3. Jul 30, 2018
  4. Jul 18, 2018
  5. Jul 06, 2018
  6. Jul 02, 2018
  7. Jun 27, 2018
  8. Jun 24, 2018
  9. Jun 06, 2018
  10. May 24, 2018
    • Oswaldo Ferreir's avatar
      Persist truncated note diffs on a new table · bb8f2520
      Oswaldo Ferreir authored
      We request Gitaly in a N+1 manner to build discussion diffs. Once the diffs are from different revisions, it's hard to make a single request to the service in order to build the whole response.
      With this change we solve this problem and simplify a lot fetching this piece of info.
      bb8f2520
  11. May 07, 2018
  12. May 04, 2018
  13. May 02, 2018
  14. Apr 25, 2018
    • Sean McGivern's avatar
      Move NotificationService calls to Sidekiq · b5042e53
      Sean McGivern authored
      The NotificationService has to do quite a lot of work to calculate the
      recipients for an email. Where possible, we should try to avoid doing this in an
      HTTP request, because the mail are sent by Sidekiq anyway, so there's no need to
      schedule those emails immediately.
      
      This commit creates a generic Sidekiq worker that uses Global ID to serialise
      and deserialise its arguments, then forwards them to the NotificationService.
      The NotificationService gains an `#async` method, so you can replace:
      
          notification_service.new_issue(issue, current_user)
      
      With:
      
          notification_service.async.new_issue(issue, current_user)
      
      And have everything else work as normal, except that calculating the recipients
      will be done by Sidekiq, which will then schedule further Sidekiq jobs to send
      each email.
      b5042e53
  15. Apr 24, 2018
  16. Apr 20, 2018
  17. Apr 05, 2018
  18. Mar 30, 2018
    • Sean McGivern's avatar
      Send emails for issues due tomorrow · 2db218f8
      Sean McGivern authored
      Also, refactor the mail sending slightly: instead of one worker sending all
      emails, create a worker per project with issues due, which will send all emails
      for that project.
      2db218f8
  19. Mar 26, 2018
  20. Mar 09, 2018
  21. Mar 06, 2018
  22. Mar 01, 2018
  23. Feb 28, 2018
  24. Feb 26, 2018
Loading