CipherLabs
/
hyperlane-monorepo
mirror of https://github.com/hyperlane-xyz/hyperlane-monorepo
2
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
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.
1644 Commits
483 Branches
322 Tags
230 MiB
Tag: Branch: Tree: 04bdce0877
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '04bdce0877'
${ noResults }
hyperlane-monorepo/rust/utils/run-locally/Cargo.toml

17 lines
419 B
Raw Normal View History Unescape

E2E testing workflow (#679) * Work on new e2e script * new e2e mimics old * Support CI mode * Kathy CI mode * remove old script * e2e workflow * Update readme * fix workflow * split build from run * change build target * Use lighter-weight http client * fix typo * better handling for stopping children * Fix url * Support multiple filters * cache node modules * cache yarn build * ci cleanup * Cleanup and updates * requested changes
2 years ago
[package]
name = "run-locally"
Better rust package management (#1975) ### Description At the suggestion of @tkporter this moves common dependencies and configuration to use the new(ish) cargo workspace configuration feature. This was added in July 2022 and allows us to ensure all versions and configurations are the same across different crates. It does not decrease the typing, but it does reduce the updates required when we go to update a package and keeps duplicates next to each other. This PR does not change any package versions or add/remove any packages. It only moves the configuration. ### Drive-by changes Also sorted packages by name. ### Related issues ### Backward compatibility _Are these changes backward compatible?_ Yes _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Manual
2 years ago
documentation.workspace = true
edition.workspace = true
homepage.workspace = true
license-file.workspace = true
publish.workspace = true
version.workspace = true
E2E testing workflow (#679) * Work on new e2e script * new e2e mimics old * Support CI mode * Kathy CI mode * remove old script * e2e workflow * Update readme * fix workflow * split build from run * change build target * Use lighter-weight http client * fix typo * better handling for stopping children * Fix url * Support multiple filters * cache node modules * cache yarn build * ci cleanup * Cleanup and updates * requested changes
2 years ago
[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
E2E testing workflow (#679) * Work on new e2e script * new e2e mimics old * Support CI mode * Kathy CI mode * remove old script * e2e workflow * Update readme * fix workflow * split build from run * change build target * Use lighter-weight http client * fix typo * better handling for stopping children * Fix url * Support multiple filters * cache node modules * cache yarn build * ci cleanup * Cleanup and updates * requested changes
2 years ago
maplit = "1.0"
Update Agents (#2159) ### Description Update rust toolchain and packages. ### Drive-by changes No ### Related issues ### Backward compatibility _Are these changes backward compatible?_ Yes _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing _What kind of testing have these changes undergone?_ Unit Tests
2 years ago
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"
E2E testing workflow (#679) * Work on new e2e script * new e2e mimics old * Support CI mode * Kathy CI mode * remove old script * e2e workflow * Update readme * fix workflow * split build from run * change build target * Use lighter-weight http client * fix typo * better handling for stopping children * Fix url * Support multiple filters * cache node modules * cache yarn build * ci cleanup * Cleanup and updates * requested changes
2 years ago
ureq = { version = "2.4", default-features = false }
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
which = "4.4"