BigW Consortium Gitlab

  1. 04 Sep, 2017 3 commits
  2. 31 Aug, 2017 4 commits
    • Implement the implied CI/CD config for AutoDevOps · 6ed49040
      Zeger-Jan van de Weg authored
      Behind an application setting, which defaults to false, this commit
      implements the implied CI/CD config. Which means that in the case we
      can't find the `.gitlab-ci.yml` on the commit we want to start a
      pipeline for, we fall back to an implied configuration.
      
      For now the Bash template has been copied to
      `Auto-Devops.gitlab-ci.yml` so the tests actually work.
      
      Fixes #34777
    • `current_application_settings` belongs on `Gitlab::CurrentSettings` · 5883ce95
      Sean McGivern authored
      The initializers including this were doing so at the top level, so every object
      loaded after them had a `current_application_settings` method. However, if
      someone had rack-attack enabled (which was loaded before these initializers), it
      would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
      have that method.
      
      To fix this:
      
      1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
         `Object.new.current_application_settings` to work.
      2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
         like that in several places.
      3. Change the initializers to use that new form.
    • Don't show references to Pages when not available · 04cd47dd
      Zeger-Jan van de Weg authored
      In this instance its subgroups, and given we can't deploy it, we
      shouldn't allow it to be shown.
      
      Fixes gitlab-org/gitlab-ce#34864
  3. 30 Aug, 2017 1 commit
  4. 29 Aug, 2017 1 commit
  5. 25 Aug, 2017 2 commits
  6. 24 Aug, 2017 2 commits
  7. 23 Aug, 2017 2 commits
    • Remove unwanted refs after importing a project · 5f811894
      Lin Jen-Shin authored
      Because we don't need them, and they would slow down
      the repository, keeping unneeded objects as well.
      
      We could also consider doing this in regular housekeeping.
    • Cache the number of open issues and merge requests · 6ec53f5d
      Yorick Peterse authored
      Every project page displays a navigation menu that in turn displays the
      number of open issues and merge requests. This means that for every
      project page we run two COUNT(*) queries, each taking up roughly 30
      milliseconds on GitLab.com. By caching these numbers and refreshing them
      whenever necessary we can reduce loading times of all these pages by up
      to roughly 60 milliseconds.
      
      The number of open issues does not include confidential issues. This is
      a trade-off to keep the code simple and to ensure refreshing the data
      only needs 2 COUNT(*) queries instead of 3. A downside is that if a
      project only has 5 confidential issues the counter will be set to 0.
      
      Because we now have 3 similar counting service classes the code
      previously used in Projects::ForksCountService has mostly been moved to
      Projects::CountService, which in turn is reused by the various service
      classes.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
  8. 22 Aug, 2017 11 commits
  9. 18 Aug, 2017 1 commit
  10. 17 Aug, 2017 3 commits
  11. 15 Aug, 2017 1 commit
  12. 14 Aug, 2017 2 commits
  13. 10 Aug, 2017 1 commit
  14. 08 Aug, 2017 2 commits
  15. 07 Aug, 2017 1 commit
  16. 04 Aug, 2017 1 commit
  17. 01 Aug, 2017 2 commits