mattermost/server/scripts/esrupgrades/esr.common.mysql.preprocess.sql

24 lines
1.7 KiB
MySQL
Raw Permalink Normal View History

MM-51095: Foundation for ESR upgrade scripts (#22448) * Add ESR upgrade migration and CI job to verify it The script was generated as a simple concatenation of migrations in the interval [54, 101] through: files=`for i in $(seq 54 101); do ls mysql/$(printf "%06d" $i)*up.sql; done` tail -n +1 $files > ../esrupgrades/esr.5.37-7.8.mysql.up.sql The CI job runs the migration both through the server and the script, and for now uploads the dumps generated for manual inspection. An automatic check for differences is still needed. * Remove debug print in script * Fix idx_uploadsessions_type creation * Ignore tables db_lock and db_migration on dump * Split workflow in two parallel jobs * Diff dumps and upload the result * Add cleanup script * Use DELIMITER in the script to use mysql CLI This allows us to remove the complexity of using a different Go script inside a Docker image. * Standardize Roles between migrations Document and cleanup code. * Upload diff only if it is not empty * Trigger action only when related files change * Add a global timeout to the job * Generalize ESR to ESR upgrade action (#22573) * Generalize action * Use logs to ensure migrations are finished * Add migrations from 5.37 to 6.3 * Remove tables in cleanup script, not through dump * Add initial-version input to common action * Add migration from 6.3 to 7.8 * Remove action debug line * ESR Upgrade: One procedure per table in the v5.37 > v7.8 upgrade script (#22590) * Squash Users-related migrations in one query * Squash Drafts-related migrations in one query * Squash UploadSessions-related migrations in one query * Squash Threads-related migrations in one query * Squash Channels-related migrations in one query * Squash ChannelMembers-related migrations in one query * Squash Jobs-related migrations in one query * Squash Sessions-related migrations in one query * Squash Status-related migrations in one query * Squash Posts-related migrations in one query * Squash TeamMembers-related migrations in one query * Squash Schemes-related migrations in one query * Squash CommandWebhooks-related migrations in one query * Squash OAuthApps-related migrations in one query * Squash Teams-related migrations in one query * Squash Reactions-related migrations in one query * Squash PostReminders-related migrations in one query * Adapt ThreadMemberships migration to unified style * Adapt LinkMetadata migrations to unified style * Adapt GroupChannels migration to unified style * Adapt PluginKVStore migration to unified style * Adapt UserGroups migration to unified style * Adapt FileInfo migration to unified style * Adapt SidebarCategories migration to unified style * Remove blank line * Use tabs everywhere * Wrap every procedure with log statements * Remove space before parentheses in procedure call * Remove spurious extra line * Merge two equal consecutive conditionals * Avoid the double list of conditions/queries * Fix variable name * Remove outdated comment * Add a preprocess phase with corresponding scripts * Join all preprocess scripts setting ExpiresAt to 0 This preprocessing is something we should always do, no matter the input DB, so we can use a common script for all cases instead of repeating the same code in multiple files. * Add system-bot if it does not exist * Cleanup the ProductNoticeViewState table * Fix SQL * Move esrupgrades directory under server/ * Update paths in Github action * Fix trigger path for CI
2023-04-20 13:41:36 -04:00
/* The sessions in the DB dump may have expired before the CI tests run, making
the server remove the rows and generating a spurious diff that we want to avoid.
In order to do so, we mark all sessions' ExpiresAt value to 0, so they never expire. */
UPDATE Sessions SET ExpiresAt = 0;
/* The dump may not contain a system-bot user, in which case the server will create
one if it's not shutdown before a job requests it. This situation creates a flaky
tests in which, in rare ocassions, the system-bot is indeed created, generating a
spurious diff. We avoid this by making sure that there is a system-bot user and
corresponding bot */
DELIMITER //
CREATE PROCEDURE AddSystemBotIfNeeded ()
BEGIN
DECLARE CreateSystemBot BOOLEAN;
SELECT COUNT(*) = 0 FROM Users WHERE Username = 'system-bot' INTO CreateSystemBot;
IF CreateSystemBot THEN
/* These values are retrieved from a real system-bot created by a server */
INSERT INTO `Bots` VALUES ('nc7y5x1i8jgr9btabqo5m3579c','','phxrtijfrtfg7k4bwj9nophqyc',0,1681308600015,1681308600015,0);
INSERT INTO `Users` VALUES ('nc7y5x1i8jgr9btabqo5m3579c',1681308600014,1681308600014,0,'system-bot','',NULL,'','system-bot@localhost',0,'','System','','','system_user',0,'{}','{\"push\": \"mention\", \"email\": \"true\", \"channel\": \"true\", \"desktop\": \"mention\", \"comments\": \"never\", \"first_name\": \"false\", \"push_status\": \"away\", \"mention_keys\": \"\", \"push_threads\": \"all\", \"desktop_sound\": \"true\", \"email_threads\": \"all\", \"desktop_threads\": \"all\"}',1681308600014,0,0,'en','{\"manualTimezone\": \"\", \"automaticTimezone\": \"\", \"useAutomaticTimezone\": \"true\"}',0,'',NULL);
END IF;
END//
DELIMITER ;
CALL AddSystemBotIfNeeded();