CI: Ensure table locks are in place after recreation of databases
What does this MR do and why?
When a GitLab instance is running on two databases, we have table triggers in place that prevents updates: tables in 'ci' database that are part of 'main' can not be modified. And tables in 'main' database that are part of 'ci' are also locked for changes.
These locks have also been enabled on CI (test) so we can early catch issues with decomposed database setup.
However, it turned out that these locks got removed on CI. After a lot of digging, it turns out we do recreate the database in some situations. Because all the tables are dropped and restored, the triggers are no longer created on the tables. So we need to do ensure they are put back in place.
So this MR will run Gitlab::Database::TablesLocker.new.lock_writes
after the databases has been recreated.
Issue: #392004 (closed)
How to set up and validate locally
Modify 20221108045019_truncate_timeline_event_tags_table.rb
: remove the early return in the up
method.
diff --git a/db/post_migrate/20221108045019_truncate_timeline_event_tags_table.rb b/db/post_migrate/20221108045019_truncate_timeline_event_tags_table.rb
index a576f9e860f9..37e6a21abed1 100644
--- a/db/post_migrate/20221108045019_truncate_timeline_event_tags_table.rb
+++ b/db/post_migrate/20221108045019_truncate_timeline_event_tags_table.rb
@@ -4,8 +4,6 @@ class TruncateTimelineEventTagsTable < Gitlab::Database::Migration[2.0]
disable_ddl_transaction!
def up
- return unless Gitlab::Database.gitlab_schemas_for_connection(connection).include?(:gitlab_main)
-
execute('TRUNCATE TABLE incident_management_timeline_event_tags, incident_management_timeline_event_tag_links')
end
--
2.39.1
- Run
RAILS_ENV=test bundle exec rake gitlab:db:lock_writes && rspec spec/migrations/sync_new_amount_used_for_ci_project_monthly_usages_spec.rb
on this branch: the specs should fail (which is good) - Run the same spec with the same diff applied on master: the specs should pass (which is not good)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.