Read about our upcoming Code of Conduct on this issue

  1. 31 Jan, 2017 1 commit
    • Kamil Trzcinski's avatar
      Add GitLab Pages · bc5e3a4463d6
      Kamil Trzcinski authored
      - The pages are created when build artifacts for `pages` job are uploaded
      - Pages serve the content under: http://group.pages.domain.com/project
      - Pages can be used to serve the group page, special project named as host: group.pages.domain.com
      - User can provide own 403 and 404 error pages by creating 403.html and 404.html in group page project
      - Pages can be explicitly removed from the project by clicking Remove Pages in Project Settings
      - The size of pages is limited by Application Setting: max pages size, which limits the maximum size of unpacked archive (default: 100MB)
      - The public/ is extracted from artifacts and content is served as static pages
      - Pages asynchronous worker use `dd` to limit the unpacked tar size
      - Pages needs to be explicitly enabled and domain needs to be specified in gitlab.yml
      - Pages are part of backups
      - Pages notify the deployment status using Commit Status API
      - Pages use a new sidekiq queue: pages
      - Pages use a separate nginx config which needs to be explic...
      bc5e3a4463d6
  2. 30 Jan, 2017 1 commit
  3. 27 Jan, 2017 4 commits
  4. 25 Jan, 2017 1 commit
  5. 23 Jan, 2017 1 commit
  6. 15 Jan, 2017 2 commits
  7. 11 Jan, 2017 1 commit
  8. 08 Jan, 2017 1 commit
    • Yorick Peterse's avatar
      Remove the project_authorizations.id column · 969751d02ea0
      Yorick Peterse authored
      This column used to be a 32 bits integer, allowing for only a maximum of
      2 147 483 647 rows. Given enough users one can hit this limit pretty
      quickly, as was the case for GitLab.com.
      
      Changing this type to bigint (= 64 bits) would give us more space, but
      we'd eventually hit the same limit given enough users and projects. A
      much more sustainable solution is to simply drop the "id" column.
      
      There were only 2 lines of code depending on this column being present,
      and neither truly required it to be present. Instead the code now uses
      the "project_id" column combined with the "user_id" column. This means
      that instead of something like this:
      
          DELETE FROM project_authorizations
          WHERE user_id = X
          AND id = Y;
      
      We now run the following when removing rows:
      
          DELETE FROM project_authorizations
          WHERE user_id = X
          AND project_id = Y;
      
      Since both user_id and project_id are indexed this should not slow down
      the DELETE query.
      
      This commit also removes the "dependent: destroy" clause from the
      "project_authorizations" relation in the User and Project models.
      Keeping this prevents Rails from being able to remove data as it relies
      on an "id" column being present. Since the "project_authorizations"
      table has proper foreign keys set up (with cascading removals) we don't
      need to depend on any Rails logic.
      969751d02ea0
  9. 03 Jan, 2017 2 commits
  10. 24 Dec, 2016 2 commits
  11. 23 Dec, 2016 1 commit
  12. 21 Dec, 2016 1 commit
    • Markus Koller's avatar
      Add more storage statistics · 4571941f6307
      Markus Koller authored
      This adds counters for build artifacts and LFS objects, and moves
      the preexisting repository_size and commit_count from the projects
      table into a new project_statistics table.
      
      The counters are displayed in the administration area for projects
      and groups, and also available through the API for admins (on */all)
      and normal users (on */owned)
      
      The statistics are updated through ProjectCacheWorker, which can now
      do more granular updates with the new :statistics argument.
      4571941f6307
  13. 20 Dec, 2016 2 commits
  14. 19 Dec, 2016 1 commit
  15. 16 Dec, 2016 3 commits
  16. 15 Dec, 2016 2 commits
  17. 14 Dec, 2016 1 commit
  18. 08 Dec, 2016 1 commit
  19. 06 Dec, 2016 1 commit
  20. 02 Dec, 2016 1 commit
  21. 29 Nov, 2016 1 commit
  22. 23 Nov, 2016 5 commits
  23. 21 Nov, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor cache refreshing/expiring · f10e7ac7c903
      Yorick Peterse authored
      This refactors repository caching so it's possible to selectively
      refresh certain caches, instead of just expiring and refreshing
      everything.
      
      To allow this the various methods that were cached (e.g. "tag_count" and
      "readme") use a similar pattern that makes expiring and refreshing
      their data much easier.
      
      In this new setup caches are refreshed as follows:
      
      1. After a commit (but before running ProjectCacheWorker) we expire some
         basic caches such as the commit count and repository size.
      
      2. ProjectCacheWorker will recalculate the commit count, repository
         size, then refresh a specific set of caches based on the list of
         files changed in a push payload.
      
      This requires a bunch of changes to the various methods that may be
      cached. For one, data should not be cached if a branch used or the
      entire repository does not exist. To prevent all these methods from
      handling this manually this is taken care of in
      Repository#cache_method_output. Some methods still manually check for
      the existence of a repository but this result is also cached.
      
      With selective flushing implemented ProjectCacheWorker no longer uses an
      exclusive lease for all of its work. Instead this worker only uses a
      lease to limit the number of times the repository size is updated as
      this is a fairly expensive operation.
      f10e7ac7c903
  24. 18 Nov, 2016 3 commits