Initial implementation

[andreibancioiu]

Code moved from multiversx/mx-chain-scripts#36.

These scripts allow one to use multiple versions of the MultiversX node, in sequence, to sync (from the deep past) or run import-db flows.

Primary reason: at some point, we'd like to drop legacy code from the newest (current) versions of the Node. Though, we have to be able to still process blocks from the deep past within some flows such as import-db, sync from genesis etc.

Configuration files:

• build configuration
• driver configuration (lanes and stages)

Notes:

• generally speaking, a processing lane would correspond to a given network shard (this is not a constraint, though). A lane has more stages - each stage references a specific configuration & node binary. A stage runs until a specific condition (configured) is met. Then, the next stage on the lane follows and so on.
• in order to enable ES indexing, pass a custom prefs.toml using the node arguments, in the driver configuration file.

Also see: README.

[Copilot]

Pull Request Overview

Initial implementation of multistage scripts to manage sequential node versions for sync and import-db flows.

• Introduces core modules for configuration parsing, lane and stage orchestration, Go build environment, and shared utilities.
• Adds CLI drivers (build.py, driver.py) plus sample JSON configs for build, sync, and import-db workflows.
• Provides project setup files (pyrightconfig.json, .flake8) and updates README.

Reviewed Changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pyrightconfig.json	Add Pyright type-checking config
.flake8	Configure Flake8 to ignore line-length
multistage/constants.py	Define magic numbers and file-mode constants
multistage/errors.py	Introduce custom error classes
multistage/shared.py	Implement archive download & extraction
multistage/config.py	Parse and validate driver/build configurations
multistage/golang.py	Set up Go environment and build helper functions
multistage/build.py	Build CLI entrypoint for compiling node binaries
multistage/driver.py	Driver CLI entrypoint for sync/import-db lanes
multistage/stage_controller.py	Control individual node stages (start/stop/monitor)
multistage/lane_controller.py	Coordinate multiple stages on a lane
multistage/samples/build.json	Sample build configuration
multistage/samples/testnet_sync.json	Sample sync driver configuration
multistage/samples/testnet_import_db.json	Sample import-db driver configuration
README.md	Document setup and usage flows

Comments suppressed due to low confidence (4)

multistage/config.py:133

• [nitpick] Using bin as a variable name shadows the built-in bin() function. Consider renaming to bin_path or binary_path for clarity and to avoid shadowing.

        self.bin = Path(bin).expanduser().resolve()

multistage/shared.py:13

• The fetch_archive function performs key file-system and network operations but lacks direct unit tests. Adding tests for download, extraction, and error conditions would improve confidence.

def fetch_archive(archive_url: str, destination_path: Path):

README.md:3

• [nitpick] The README uses the HTML entity & in markdown. It can be replaced with a plain & for readability and consistency.

Multi-staged sync & import-db (node versions manager).

multistage/config.py:9

• [nitpick] Public classes like BuildConfigEntry, DriverConfig, and StageConfig lack docstrings. Consider adding class and method docstrings to explain their purpose and usage.

class BuildConfigEntry:

[andreibancioiu]

Idea from Adi: keep (retain) config for every stage, might be useful for debugging.

#2