Make `ChangePersonalAccessTokensDefaultBackToEmptyArray` a "post" migration.20492-access-token-scopes

If we leave this as a regular migration, we could have the following flow:

1. Application knows nothing about scopes.
2. First migration runs, all existing personal access tokens have `api` scope
3. Application still knows nothing about scopes.
4. Second migration runs, all tokens created after this point have no scope
5. Application still knows nothing about scopes.
6. Tokens created at this time _should have the API scope, but instead have no scope_
7. Application code is reloaded, application knows about scopes
8. Tokens created after this point only have no scope if the user deliberately
   chooses to have no scopes.

Point #6 is the problem here. To avoid this, we move the second migration to a
"post" migration, which runs after the application code is deployed/reloaded.

1 files changed, 19 insertions, 0 deletions

diff --git a/db/post_migrate/20160824121037_change_personal_access_tokens_default_back_to_empty_array.rb b/db/post_migrate/20160824121037_change_personal_access_tokens_default_back_to_empty_array.rb
new file mode 100644
index 00000000000..7df561d82dd
--- /dev/null
+++ b/db/post_migrate/20160824121037_change_personal_access_tokens_default_back_to_empty_array.rb
@@ -0,0 +1,19 @@
+# The default needs to be `[]`, but all existing access tokens need to have `scopes` set to `['api']`.
+# It's easier to achieve this by adding the column with the `['api']` default (regular migration), and
+# then changing the default to `[]` (in this post-migration).
+#
+# Details: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5951#note_19721973
+
+class ChangePersonalAccessTokensDefaultBackToEmptyArray < ActiveRecord::Migration
+  include Gitlab::Database::MigrationHelpers
+
+  DOWNTIME = false
+
+  def up
+    change_column_default :personal_access_tokens, :scopes, [].to_yaml
+  end
+
+  def down
+    change_column_default :personal_access_tokens, :scopes, ['api'].to_yaml
+  end
+end