1. 16 Jan, 2019 1 commit
    • Yorick Peterse's avatar
      Fix detecting nested EE constants in RuboCop · 9722158c
      Yorick Peterse authored
      The InjectEnterpriseEditionModule cop would not detect certain nested EE
      constants such as `EE::Foo::Bar::Baz`. This could result in it not
      enforcing `prepend` being placed on the last line. This commit fixes
      this by just performing a string match on the line, instead of relying
      on AST matching.
      9722158c
  2. 13 Dec, 2018 1 commit
    • Yorick Peterse's avatar
      Added Cop for injecting EE modules · 7c580556
      Yorick Peterse authored
      This Cop enforces the rule that injecting EE modules (using prepend,
      include, or extend) is done by placing the injection on the last line of
      a file, instead of somewhere in the middle. By placing these lines at
      the very end, merge conflicts will not happen.
      7c580556
  3. 12 Dec, 2018 1 commit
  4. 27 Nov, 2018 1 commit
    • Toon Claes's avatar
      Make add_reference cop accept a hash for :index · 54b63919
      Toon Claes authored
      It might happen you want to make the reference column have a unique
      value, or you want to create partial indexes. So instead of only
      accepting a `true` value, also accept a hash of options.
      54b63919
  5. 22 Nov, 2018 1 commit
  6. 15 Oct, 2018 1 commit
  7. 24 Sep, 2018 1 commit
  8. 21 Sep, 2018 1 commit
  9. 17 Sep, 2018 1 commit
    • Yorick Peterse's avatar
      Added FromUnion to easily select from a UNION · 8a72f5c4
      Yorick Peterse authored
      This commit adds the module `FromUnion`, which provides the class method
      `from_union`. This simplifies the process of selecting data from the
      result of a UNION, and reduces the likelihood of making mistakes. As a
      result, instead of this:
      
          union = Gitlab::SQL::Union.new([foo, bar])
      
          Foo.from("(#{union.to_sql}) #{Foo.table_name}")
      
      We can now write this instead:
      
          Foo.from_union([foo, bar])
      
      This commit also includes some changes to make this new setup work
      properly. For example, a bug in Rails 4
      (https://github.com/rails/rails/issues/24193) would break the use of
      `from("sub-query-here").includes(:relation)` in certain cases. There was
      also a CI query which appeared to repeat a lot of conditions from an
      outer query on an inner query, which isn't necessary.
      
      Finally, we include a RuboCop cop to ensure developers use this new
      module, instead of using Gitlab::SQL::Union directly.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51307
      8a72f5c4
  10. 11 Sep, 2018 1 commit
  11. 05 Sep, 2018 1 commit
  12. 29 Aug, 2018 4 commits
  13. 25 Aug, 2018 1 commit
    • Bob Van Landuyt's avatar
      Reject ruby interpolation in externalized strings · 08c0a1b8
      Bob Van Landuyt authored
      When using ruby interpolation in externalized strings, they can't be
      detected. Which means they will never be presented to be translated.
      
      To mix variables into translations we need to use `sprintf`
      instead.
      
      Instead of:
      
          _("Hello #{subject}")
      
      Use:
      
          _("Hello %{subject}) % { subject: 'world' }
      08c0a1b8
  14. 16 Aug, 2018 2 commits
  15. 08 Aug, 2018 1 commit
  16. 20 Jun, 2018 1 commit
    • Bob Van Landuyt's avatar
      Add a cop for `FinderMethods` · f3f1df14
      Bob Van Landuyt authored
      This notifies developers when calling `find(_by!)` chained on
      `execute`. And suggests using the methods from `FinderMethods`. These
      will perform the correct authorization checks on the resource when it
      is found.
      f3f1df14
  17. 19 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Disallow methods that copy data on large tables · eb086a4b
      Sean McGivern authored
      {change_column_type,rename_column}_concurrently both copy data from one column
      to another during a migration, which should not be done on GitLab.com. Instead,
      we should use background migrations.
      eb086a4b
  18. 29 May, 2018 1 commit
  19. 18 Apr, 2018 2 commits
  20. 09 Apr, 2018 1 commit
  21. 06 Apr, 2018 1 commit
  22. 21 Mar, 2018 1 commit
  23. 12 Jan, 2018 2 commits
  24. 11 Jan, 2018 1 commit
  25. 22 Dec, 2017 1 commit
  26. 13 Dec, 2017 1 commit
  27. 11 Dec, 2017 1 commit
    • Sean McGivern's avatar
      Add cop for use of remove_column · 1ab33b15
      Sean McGivern authored
      remove_column should only be used in the up (or change) step of a migration if
      it's a post-deployment migration. Otherwise there will be downtime due to the
      ActiveRecord column cache, which we can avoid by using the IgnorableColumn
      concern in combination with a post-deployment migration.
      1ab33b15
  28. 22 Nov, 2017 1 commit
  29. 21 Nov, 2017 1 commit
  30. 17 Nov, 2017 2 commits
    • Lin Jen-Shin's avatar
      Allow initialize method and single ivar · 7441c7af
      Lin Jen-Shin authored
      7441c7af
    • Sean McGivern's avatar
      Prevent update_column_in_batches on large tables · d8be9814
      Sean McGivern authored
      add_column_with_default is implemented in terms of update_column_in_batches, but
      update_column_in_batches can be used independently. Neither of these should be
      used on the specified large tables, because they will cause issues on large
      instances like GitLab.com.
      
      This also ignores the cop for all existing migrations, renaming
      AddColumnWithDefaultToLargeTable where appropriate.
      d8be9814
  31. 16 Nov, 2017 1 commit
  32. 21 Oct, 2017 1 commit
  33. 18 Oct, 2017 1 commit