discourse/config/initializers/000-post_migration.rb

# frozen_string_literal: true

unless Discourse.skip_post_deployment_migrations?
  ActiveRecord::Migrator.migrations_paths << Rails.root.join(
    Discourse::DB_POST_MIGRATE_PATH
  ).to_s
end
DEV: enable frozen string literal on all files This reduces chances of errors where consumers of strings mutate inputs and reduces memory usage of the app. Test suite passes now, but there may be some stuff left, so we will run a few sites on a branch prior to merging 2019-05-03 06:17:27 +08:00			`# frozen_string_literal: true`

DEV: Support post deployment migrations for plugins. 2018-10-09 13:11:45 +08:00			`unless Discourse.skip_post_deployment_migrations?`
FIX: Use migrations path for post_migrate (#8133) That is a problem after upgrade to Rails 6. It was partially fixed here: https://github.com/discourse/discourse/commit/025d4ee91f4727540c749e2162680e1042c34376 2019-10-02 13:28:38 +08:00			`ActiveRecord::Migrator.migrations_paths << Rails.root.join(`
FEATURE: Post deployment migrations. (#6406) This moves us away from the delayed drops pattern which was problematic on two counts. First, it uses a hardcoded "delay for" duration which may be too short for certain deployment strategies. Second, delayed drop doesn't ensure that it only runs after the latest application code has been deployed. If the migration runs and the application code fails to deploy, running the migration after "delay for" has been met will cause the application to blow up. The new strategy allows post deployment migrations to be skipped if the env `SKIP_POST_DEPLOYMENT_MIGRATIONS` is provided. ``` SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate -> deploy app servers SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate ``` To aid with the generation of a post deployment migration, a generator has been added. Simply run `rails generate post_migration`. 2018-10-08 15:47:38 +08:00			`Discourse::DB_POST_MIGRATE_PATH`
			`).to_s`
			`end`