BigW Consortium Gitlab

  1. 11 Apr, 2016 1 commit
  2. 04 Apr, 2016 12 commits
    • Add notice about GitLab Runner to requirements docs · 3cf51236
      Grzegorz Bizon authored
      This is related to !14589, and problems that may stem from running
      GitLab Runner on same machine user installed GitLab web app on.
    • Merge branch '8.7-rc1' into 'master' · 438e0ce8
      Yorick Peterse authored
      Added 8.7 install/update guides
      
      See merge request !3517
    • Added 8.7 install/update guides · 6ddfd496
      Yorick Peterse authored
      [ci skip]
    • Merge branch 'banzai-webscale' into 'master' · 4bf30279
      Douwe Maan authored
      Improve rendering performance of Banzai
      
      Related issues:
      
      * gitlab-org/gitlab-ce#14315
      * gitlab-org/gitlab-ce#13651
      
      TODO:
      
      * [x] `Banzai::Filter::ExternalIssueReferenceFilter#call` calls `Project#default_issues_tracker?` which runs a query on every call. Memoizing this only works if the `Project` instance is shared between instances of this filter. Either way it should at most only run this method once.
      * [x] Fix the two failing specs
      * [x] Clean of the various `call` methods in the filters where I inlined methods
      * [x] Remove the `replace_XXX` methods in ReferenceFilter now that they're no longer used.
      
      See merge request !3389
    • Cleaned up caching in AbstractReferenceFilter · 915fd3f9
      Yorick Peterse authored
      Cleaning this up any further is a bit tricky as the caches in question
      should only be evaluated if RequestStore is actually enabled.
    • Merge branch 'issue_14853' into 'master' · 3dd91f55
      Yorick Peterse authored
      Fix bug related to filtering Issues by Label/Milestone.
      
      See merge request !3499
    • Cache default_issues_tracker? in Banzai · 7f0fd73e
      Yorick Peterse authored
      Every object processed by ExternalIssueReferenceFilter can return a
      different Project instance when calling "project". For example, every
      note processed will have it's own associated Project. If we were to
      cache Project#default_issues_tracker? on Project level this would have
      no impact on Markdown rendering timings as the cache would have to be
      built for every Project instance without it ever being re-used.
      
      To work around this we cache Project#default_issues_tracker? in
      Banzai::Filter::ExternalIssueReferenceFilter using the project's _id_
      instead of the whole object. This setup allows re-using of the cached
      data even when the Project instances used are different, as long as the
      actual project IDs are the same.
    • Memoize object class titles · 9fa94326
      Yorick Peterse authored
      For an issue with around 200 notes this cuts down timings by around 150
      milliseconds.
    • Cache Banzai class methods returning static data · 8c49eaa9
      Yorick Peterse authored
      These methods always return the same data for every class so there's no
      point in computing their values on every call.
    • Refactor processing of various Banzai filters · 14114805
      Yorick Peterse authored
      These filters now use a single iteration over all the document nodes
      instead of multiple ones. This in turn allows variables to be re-used
      (e.g. links only have to be unescaped once). Combined with some other
      refactoring this can drastically reduce render timings.
    • Cache Banzai projects/objects using RequestStore · 57bde0ce
      Yorick Peterse authored
      This was originally suggested by @ayufan and modified to be a bit
      cleaner and use RequestStore instead of a regular Hash.
      
      By caching the output of the two methods involved the number of queries
      is reduced significantly. For example, for an issue with 200 notes (of
      which 100 reference a number of merge requests) this cuts down the
      amount of queries from around 6300 to around 3300.
  3. 03 Apr, 2016 3 commits
  4. 02 Apr, 2016 4 commits
  5. 01 Apr, 2016 20 commits