The home for Hyperlane core contracts, sdk packages, and other infrastructure
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
hyperlane-monorepo/rust/utils/run-locally/Cargo.toml

21 lines
494 B

cargo-features = ["workspace-inheritance"]
[package]
name = "run-locally"
documentation.workspace = true
edition.workspace = true
homepage.workspace = true
license-file.workspace = true
publish.workspace = true
version.workspace = true
[dependencies]
ctrlc = "3.2"
E2E Sealevel Prep (#2551) ### Description This PR hardens the e2e test pipeline to failure cases we have seen frequently and also makes the code more generic to better support future environments such as sealevel. The original ticket describes making one or more traits to help with this but after much experimentation and consideration, I feel that doing so would make the code unnecessarily complex and less flexible to future changes. My solution instead after talking with @tkporter regarding the sealvel e2e test pathway is to: 1) get utility code out of the way to make it more clear what the execution path is 2) simplify the process of running build tasks in the background so that as we add more envs we can have multiple things running concurrently without difficulty 3) standardize our program execution pattern to reduce the understanding overhead of the main execution path The main thing I kept running into every time I tried to create traits is that we ultimately need a lot of env and context which means either arg passing or even more structures to hold them or we statically code it into that module. The last option was the cleanest but at that point there isn't much difference between creating a trait and just defining a function to call. And even then there is still some live data we define as we go in main that is bulky to pass around but it might become worth it depending. Also the amount of support code for traits kept trying to ballon because we would need something that constructs the "components", and then runs each of the stages, but it also would need to still know what order to run things in, possibly even within each of those steps. ### Drive-by changes - Now watches agents to detect early termination - Standardizes log prefixes to distinguish between e2e logs and sub process logs - Now logs what commands are run - Standardized the program args concept to reduce param passing and better support reusable configurations - Has all build commands run asynchronously by default to prevent `spawn` commands in main - Fixed an issue where some rust components were being built twice, once as debug and again as release ### Related issues - Fixes hyperlane-xyz/issues#501 - Should help debug recent flakiness if not resolve it ### Backward compatibility Yes ### Testing Manual
1 year ago
eyre.workspace = true
maplit = "1.0"
nix = { version = "0.26", default-features = false, features = ["signal"] }
E2E Sealevel Prep (#2551) ### Description This PR hardens the e2e test pipeline to failure cases we have seen frequently and also makes the code more generic to better support future environments such as sealevel. The original ticket describes making one or more traits to help with this but after much experimentation and consideration, I feel that doing so would make the code unnecessarily complex and less flexible to future changes. My solution instead after talking with @tkporter regarding the sealvel e2e test pathway is to: 1) get utility code out of the way to make it more clear what the execution path is 2) simplify the process of running build tasks in the background so that as we add more envs we can have multiple things running concurrently without difficulty 3) standardize our program execution pattern to reduce the understanding overhead of the main execution path The main thing I kept running into every time I tried to create traits is that we ultimately need a lot of env and context which means either arg passing or even more structures to hold them or we statically code it into that module. The last option was the cleanest but at that point there isn't much difference between creating a trait and just defining a function to call. And even then there is still some live data we define as we go in main that is bulky to pass around but it might become worth it depending. Also the amount of support code for traits kept trying to ballon because we would need something that constructs the "components", and then runs each of the stages, but it also would need to still know what order to run things in, possibly even within each of those steps. ### Drive-by changes - Now watches agents to detect early termination - Standardizes log prefixes to distinguish between e2e logs and sub process logs - Now logs what commands are run - Standardized the program args concept to reduce param passing and better support reusable configurations - Has all build commands run asynchronously by default to prevent `spawn` commands in main - Fixed an issue where some rust components were being built twice, once as debug and again as release ### Related issues - Fixes hyperlane-xyz/issues#501 - Should help debug recent flakiness if not resolve it ### Backward compatibility Yes ### Testing Manual
1 year ago
tempfile = "3.3"
ureq = { version = "2.4", default-features = false }
which = "4.4"
Solana e2e tests (#2578) ### Description Adds support for testing solana with the e2e tests. This involves 1) Downloading the pre-built solana cli tools 2) Setting up the solana configuration 3) Downloading the pre-built solana programs we need (see https://github.com/hyperlane-xyz/solana-program-library/releases/) 4) The solana programs in the repo 5) Start the solana validator 6) Deploy the solana programs 7) Deploy a warp route 8) Initialize the multisig ism and validator announce 9) Initialize a transfer 10) Wait for the message to be delivered In addition these were "woven" in with the existing E2E test logic, so for instance we only run one new validator and the existing relayer was extended to support these additional chains. This will make it much easier later on to support testes between environments. ### Drive-by changes - Fix a bug in the relayer when trying to index the mailbox - Add support in the hyperlane sealevel CLI for custom solana config paths - Fix a linker error on linux causes by not specifying `no-entrypoint` - Cleaned up unnecessary `no-entrypoint` features in libraries - Minor refactor to how we run commands to avoid arg passing - Created an easy way to define tasks that run asyncly `as_task` - Split up main logic flow into a couple files for easier reading - Use mold linker to speed up builds (well, the linking part) - Removed support for `log_all` to simplify code pathways - Added context when a child process ends unexpectedly for easier debugging - Fixed a bug in the validator where it would infinitely retry to send an announcement on failure without waiting - Cleaned up solana configs - Fixed processes hanging on exit (very annoying when testing locally since you have to manually go kill them) - Added stderr logging to the hyperlane sealevel CLI subprocess calls ### Related issues Fixes #2415 ### Backward compatibility Yes ### Testing Manual
1 year ago
macro_rules_attribute = "0.2"