Repository navigation
Use Bytebase's metadata migrations as revisions (base to 3.5) - #11
Merged
Merged
Conversation
…o 3.5 Replace the employee migrations with Bytebase's own metadata schema history, to exercise a release with many versions: - migrations/2.23.0_base.sql: the schema just before 3.0/0000, its seed data, and the rows a 2.23 server writes on first start and sign-up. - migrations/3.0 to 3.5: Bytebase's migration files, renamed to unique dotted versions (3.N.NNNN_name.sql). - migrations/3.3/3.3.0009: the history-table cleanup the 3.4 migrator ran in Go at startup. The workflows now run a local bytebase-action build on the self-hosted runner against http://localhost:8080 and authenticate through workload identity. The access token is masked and passed as BYTEBASE_ACCESS_TOKEN. The declarative workflows target the gitops-state-based project. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SQL Review Summary
Detailed Results
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First of several PRs that load Bytebase's own metadata schema history as versioned revisions, to test the release-backed plan page with many versions.
What's in it
migrations/2.23.0_base.sql: the schema just before3.0/0000(LATEST.sql+LATEST_DATA.sqlat the parent of the commit that added it), plus the rows a 2.23 server writes on first start and sign-up: one admin user (admin@example.com), the workspace ID and the auth secret. Later migrations assume those rows exist.migrations/3.0tomigrations/3.5: Bytebase's migration files, renamed fromNNNN##name.sqlto3.N.NNNN_name.sqlso every file has a unique version.migrations/3.3/3.3.0009_migrator_history_cleanup.sql: theinstance_change_historycleanup that the 3.4 migrator ran in Go at startup. No SQL file records it, and3.4.0012fails without it.schema/is unchanged.Replayed on a throwaway Postgres, one transaction per file in version order: the full set (base plus all 288 files through 3.25) applies with no errors and matches today's
LATEST.sqltable for table.Workflows
All four workflows run a local
bytebase-actionbuild on the self-hosted runner againsthttp://localhost:8080and authenticate through workload identity. The access token is masked and passed asBYTEBASE_ACCESS_TOKEN. The migration workflows target thebb-gitops-migrationdatabase group ingitops-migration-based; the declarative ones targetbb-gitops-stateingitops-state-based.🤖 Generated with Claude Code