mirror of
https://github.com/luxfi/cli.git
synced 2026-10-30 17:01:20 +00:00
zeekay
8f56009cc7
Deep audit changes: - Replace stub signature aggregator with real SDK warp implementation - Remove dead pkg/lpm package (SDK lpmintegration used instead) - Fix fs imports: use local utils.FileExists, DirExists, ExpandHome - Fix secp256k1fx imports: use node/vms/secp256k1fx - Fix platformvm imports: use node/vms/platformvm - Fix e2e test TODOs: uncomment BootstrapValidators assertions - Improve localnet stub implementations with real logic - Fix node.go fs.FileExists reference Note: Build requires GOWORK=off due to workspace dependency issues
Migrations
Why Migrations
The idea is to introduce a standardized process for internal changes of the
Lux tool which usually require scripting.
By running these migrations, we don't require external scripting, encapsulating different subsequent internal changes in sort of a managed, reproducible way which also represents its history.
The concept is obviously borrowed from databases where migrations are being applied to update database structures and its data to new versions of schemas and applications.
Limitations
Usually migrations have a rollback path which can be applied in case of failures. This tool currently does not support rollbacks.
General Structure
- The application calls all migrations implemnted when booting
- Each migration is iterated in order (the order is "enforced" via the index in the migrations map)
- Each migration checks itself if it needs to be applied
- The first migration which is getting applied prints a message to the user
- At the end of the iteration, it is checked if any migration ran. If one did, a closing message is printed
- If no migration ran at all, nothing is being printed
Implementation
- Migrations need to reside in
internal/migrations - Each new migration should be added into a separate file in the package
- Each new migration needs to implement a
migrationFunc - It adds itself to the global
migrationsmap with the next available index - Each new migration needs to check itself if it needs to be applied depending on what it does
- If it needs to be applied, it should run
printMigrationMessageas an info to the user - Otherwise it doesn't need to print anything (to not add confusion)
- Every migration is expected to clean after itself if needed