1. 22 Nov, 2018 1 commit
  2. 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
  3. 04 Aug, 2016 1 commit
    • Timothy Andrew's avatar
      Fix `#down` for two protected branches-related migrations. · 4d0461e2
      Timothy Andrew authored
      - The migrations called `add_column_with_default` with a `null` option,
        which the Rails `add_column` method accepts. This fails because
        `add_column_with_default` expects an `allow_null` option instead.
      
      - The migrations have been fixed to use `allow_null`.
      4d0461e2
  4. 29 Jul, 2016 3 commits
    • Timothy Andrew's avatar
      Implement final review comments from @rymai. · cebcc417
      Timothy Andrew authored
      1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`
      
      2. Use `can?(user, ...)` instead of `user.can?(...)`
      
      3. Add `DOWNTIME` notes to all migrations added in !5081.
      
      4. Add an explicit `down` method for migrations removing the
         `developers_can_push` and `developers_can_merge` columns, ensuring that
         the columns created (on rollback) have the appropriate defaults.
      
      5. Remove duplicate CHANGELOG entries.
      
      6. Blank lines after guard clauses.
      cebcc417
    • Timothy Andrew's avatar
      Implement review comments from @dbalexandre. · 7b2ad2d5
      Timothy Andrew authored
      1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
         `max_member_access`, which is a lot nicer.
      
      2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
         in migrations that don't need this module. Also remove comments where
         not necessary.
      
      3. Remove duplicate entry in CHANGELOG.
      
      4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
      
      5. Split the `set_access_levels!` method in two - one each for `merge` and
         `push` access levels.
      7b2ad2d5
    • Timothy Andrew's avatar
      Add a series of migrations changing the model-level design of protected branch access levels. · f1e46d1e
      Timothy Andrew authored
      1. Remove the `developers_can_push` and `developers_can_merge` boolean
         columns.
      
      2. Add two new tables, `protected_branches_push_access`, and
         `protected_branches_merge_access`. Each row of these 'access' tables is
         linked to a protected branch, and uses a `access_level` column to
         figure out settings for the protected branch.
      
      3. The `access_level` column is intended to be used with rails' `enum`,
         with `:masters` at index 0 and `:developers` at index 1.
      
      4. Doing it this way has a few advantages:
      
         - Cleaner path to planned EE features where a protected branch is
           accessible only by certain users or groups.
      
         - Rails' `enum` doesn't allow a declaration like this due to the
           duplicates. This approach doesn't have this problem.
      
             enum can_be_pushed_by: [:masters, :developers]
             enum can_be_merged_by: [:masters, :developers]
      f1e46d1e
  5. 09 Jun, 2016 1 commit
    • Sean McGivern's avatar
      Enable RuboCop for migrations · 98bb435f
      Sean McGivern authored
      Migrations shouldn't fail RuboCop checks - especially lint checks, such
      as the nested method check. To avoid changing code in existing
      migrations, add the magic comment to the top of each of them to skip
      that file.
      98bb435f
  6. 03 Jun, 2016 2 commits
  7. 25 May, 2016 1 commit
  8. 19 May, 2016 2 commits
  9. 12 May, 2016 2 commits