refactor(migrations): initial framework to build batchable migrations#57396
Closed
devversion wants to merge 3 commits intoangular:mainfrom
Closed
refactor(migrations): initial framework to build batchable migrations#57396devversion wants to merge 3 commits intoangular:mainfrom
devversion wants to merge 3 commits intoangular:mainfrom
Conversation
crisbeto
approved these changes
Aug 16, 2024
f81d4b5 to
e64aedd
Compare
Member
Author
|
Caretaker notes: Please ignore bugged GitHub reviewer on this PR. (Alex). Also, internal BUILD changes needed to land this: https://critique.corp.google.com/cl/663704366 |
Introduces a migration framework to build batchable migrations that can run in Large Scale mode against e.g. all of Google, using workers. This is the original signal input migration infrastructure extracted into a more generic framework that we can use for writing additional ones for output, signal queries etc, while making sure those are not scoped to a single `ts.Program` that limits them to per-directory execution in very large projects (e.g. G3). The migration will be updated to use this, and in 1P we will add helpers to easily integrate such migrations into a Go-based pipeline runner.
0e82fd8 to
655b328
Compare
alxhub
approved these changes
Aug 16, 2024
packages/core/schematics/utils/tsurge/helpers/group_replacements.ts
Outdated
Show resolved
Hide resolved
Configure file system globally
Contributor
|
This PR was merged into the repository by commit 368f36d. The changes were merged into the following branches: main, 18.2.x |
dylhunn
pushed a commit
that referenced
this pull request
Aug 17, 2024
Introduces a migration framework to build batchable migrations that can run in Large Scale mode against e.g. all of Google, using workers. This is the original signal input migration infrastructure extracted into a more generic framework that we can use for writing additional ones for output, signal queries etc, while making sure those are not scoped to a single `ts.Program` that limits them to per-directory execution in very large projects (e.g. G3). The migration will be updated to use this, and in 1P we will add helpers to easily integrate such migrations into a Go-based pipeline runner. PR Close #57396
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Introduces a migration framework to build batchable migrations that can run in Large Scale
mode against e.g. all of Google, using workers.
This is the original signal input migration infrastructure extracted into a more generic framework
that we can use for writing additional ones for output, signal queries etc, while making sure those
are not scoped to a single
ts.Programthat limits them to per-directory execution in very large projects (e.g. G3).The migration will be updated to use this, and in 1P we will add helpers to easily integrate such
migrations into a Go-based pipeline runner.
credits for the name to @alxhub! 🎉