BigW Consortium Gitlab

  1. 11 Apr, 2017 1 commit
  2. 10 Apr, 2017 1 commit
  3. 09 Apr, 2017 1 commit
  4. 05 Apr, 2017 1 commit
  5. 24 Mar, 2017 1 commit
  6. 20 Mar, 2017 1 commit
  7. 17 Mar, 2017 2 commits
  8. 16 Mar, 2017 1 commit
  9. 14 Mar, 2017 2 commits
  10. 13 Mar, 2017 3 commits
  11. 07 Mar, 2017 1 commit
  12. 06 Mar, 2017 1 commit
  13. 01 Mar, 2017 1 commit
    • Disable the inheritance column of services in DisableInvalidServiceTemplates migration · 2f40fc52
      Rémy Coutable authored
      The `unless defined?(Service)` was useless since in production env,
      models are eager loaded, thus we wouldn't disable the STI, resulting in
      the following error:
      
      The single-table inheritance mechanism failed to locate the subclass:
      'GitlabCiService'. This error is raised because the column 'type' is
      reserved for storing the class in case of inheritance. Please rename
      this column if you didn't intend it to be used for storing the
      inheritance class or overwrite Service.inheritance_column to use another
      column for that
      information./opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20170211073944_disable_invalid_service_templates.rb:11:in `up'
      Signed-off-by: 's avatarRémy Coutable <remy@rymai.me>
  14. 23 Feb, 2017 4 commits
  15. 16 Feb, 2017 1 commit
  16. 15 Feb, 2017 2 commits
  17. 14 Feb, 2017 10 commits
  18. 07 Feb, 2017 1 commit
  19. 24 Jan, 2017 3 commits
  20. 11 Jan, 2017 1 commit
  21. 08 Jan, 2017 1 commit
    • Remove the project_authorizations.id column · de321fbb
      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.