feat(ton): TON localnet integration #2833
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughWalkthroughThe changes introduced in this pull request primarily focus on integrating support for the TON blockchain into the existing codebase. This includes modifications to the e2e testing framework, configuration files, and the addition of new functionalities for managing TON accounts and transactions. The updates also enhance the CI workflow to accommodate testing for the TON environment, ensuring that the system can effectively interact with the TON blockchain. Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
swift1337
force-pushed
the
feat/ton-localnet
branch
from
5f5b6c5 to
fa24973
Compare
swift1337
force-pushed
the
feat/ton-localnet
branch
from
fa24973 to
ec7a217
Compare
|
!!!WARNING!!! Be very careful about using Only suppress a single rule (or a specific set of rules) within a section of code, while continuing to scan for other problems. To do this, you can list the rule(s) to be suppressed within the #nosec annotation, e.g: /* #nosec G401 */ or //#nosec G201 G202 G203 Pay extra attention to the way |
swift1337
requested review from
a team,
brewmaster012,
kingpinXD,
ws4charlie,
skosito and
fbac
as code owners
swift1337
added
TON_TESTS
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
Outside diff range and nitpick comments (13)
contrib/localnet/orchestrator/Dockerfile.fastbuild (1)
17-17: Consider marking thewait-for-ton.shscript as executable.The addition of the
wait-for-ton.shscript to the orchestrator's Docker image is a positive change that enhances the orchestration capabilities during the local network setup. However, to ensure that the script can be executed within the container, it is recommended to mark it as executable using thechmodcommand.Apply this change to mark the script as executable:
COPY contrib/localnet/scripts/wait-for-ton.sh /work/ +RUN chmod +x /work/wait-for-ton.she2e/e2etests/test_ton_deposit.go (1)
13-42: Rename the function and add a TODO comment for the actual deposit test.The function name
TestTONDepositis misleading as the actual deposit test is not implemented. Consider renaming the function to better reflect its purpose, such asTestTONE2EBoilerplateorTestTONE2ESetup.Also, add a TODO comment to implement the actual deposit test in the future.
Apply this diff to rename the function and add a TODO comment:
-func TestTONDeposit(r *runner.E2ERunner, _ []string) { +func TestTONE2EBoilerplate(r *runner.E2ERunner, _ []string) { + // TODO: Implement the actual deposit testcmd/zetae2e/local/ton.go (3)
21-31: Simplify error handling by directly returning the error.Instead of assigning the error to a variable and returning it later, you can directly return the error to make the code more concise.
- if err != nil { - return errors.Wrap(err, "unable to init ton test runner") - } + if err != nil { + return errors.Wrap(err, "unable to init ton test runner") + }
33-34: Enhance logging by using structured logging with fields.Consider using a structured logging library like
zaporlogrusto log with fields. This makes the logs more searchable and easier to parse.- tonRunner.Logger.Print("🏃 starting TON tests") + tonRunner.Logger.Info("starting TON tests", zap.String("status", "started")) startTime := time.Now() ... - tonRunner.Logger.Print("🍾 ton tests completed in %s", time.Since(startTime).String()) + tonRunner.Logger.Info("ton tests completed", zap.String("status", "completed"), zap.Duration("duration", time.Since(startTime)))Also applies to: 49-49
15-20: Remove unused parameterverbosefrom the function signature.The
verboseparameter is not used within the function body and can be removed to simplify the function signature.-func tonTestRoutine( - conf config.Config, - deployerRunner *runner.E2ERunner, - verbose bool, - testNames ...string, -) func() error { +func tonTestRoutine( + conf config.Config, + deployerRunner *runner.E2ERunner, + testNames ...string, +) func() error {cmd/zetae2e/init.go (1)
31-32: Consider using a more generic default value for--tonSidecarURL.The addition of the
--tonSidecarURLflag enhances the flexibility of the command by allowing users to specify the URL for the TON sidecar service. The flag follows the naming convention and usage pattern consistent with other existing flags.However, the default value
"http://ton:8111"assumes a specific URL for the TON sidecar service, which may not be applicable in all environments. Consider using a more generic default value or an empty string to avoid making assumptions about the TON sidecar service URL.-StringVar(&initConf.RPCs.TONSidecarURL, "tonSidecarURL", "http://ton:8111", "--tonSidecarURL http://ton:8111") +StringVar(&initConf.RPCs.TONSidecarURL, "tonSidecarURL", "", "--tonSidecarURL <url>")e2e/runner/ton/accounts_test.go (2)
13-53: LGTM with minor suggestions!The test is well-structured and follows the Arrange-Act-Assert pattern. It effectively tests the building of a gateway deployment payload by comparing the generated state string with an expected value.
Consider the following suggestions to improve readability:
- Use more descriptive variable names, such as
gatewayCodeCellandgatewayStateCell, instead ofcodeCellandstateCell.- Add comments to explain the purpose of each section of the test (Arrange, Act, Assert) and the significance of the expected state value.
Tools
Gitleaks
16-16: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
55-66: LGTM with a suggestion to add more assertions!The test is correctly structured and follows the Arrange-Act-Assert pattern. It effectively tests the construction of a wallet from a random seed by asserting that the returned values are not nil and that there are no errors.
Consider adding more assertions to verify the correctness of the constructed wallet, such as:
- Checking the wallet address against an expected format or prefix.
- Checking the initial balance of the wallet (should be zero).
- Checking the public key of the wallet against the derived public key from the seed.
These additional assertions will provide more confidence in the correctness of the wallet construction process.
e2e/runner/ton/clients.go (2)
80-98: Consider extracting error handling logic.The
GetFaucetfunction is correctly implemented, retrieving the faucet information from the TON sidecar service. However, the error handling logic could be extracted into a separate function to improve readability and reusability.Here's an example of how the error handling logic can be extracted:
func (c *SidecarClient) GetFaucet(ctx context.Context) (Faucet, error) { resp, err := c.get(ctx, "faucet.json") if err != nil { return Faucet{}, err } defer resp.Body.Close() if err := checkResponseStatus(resp); err != nil { return Faucet{}, err } var faucet Faucet if err := json.NewDecoder(resp.Body).Decode(&faucet); err != nil { return Faucet{}, err } return faucet, nil } func checkResponseStatus(resp *http.Response) error { if resp.StatusCode != http.StatusOK { return fmt.Errorf("unexpected response status: %d", resp.StatusCode) } return nil }
101-121: Consider extracting response body reading logic.The
Statusfunction is correctly implemented, checking the health status of the TON node by making an HTTP GET request to the/statusendpoint. However, the response body reading logic could be extracted into a separate function to improve readability and reusability.Here's an example of how the response body reading logic can be extracted:
func (c *SidecarClient) Status(ctx context.Context) error { resp, err := c.get(ctx, "status") if err != nil { return err } defer resp.Body.Close() body, err := readResponseBody(resp) if err != nil { return err } if resp.StatusCode != http.StatusOK { return errors.Wrapf(ErrNotHealthy, "status %d. %s", resp.StatusCode, string(body)) } return nil } func readResponseBody(resp *http.Response) ([]byte, error) { body, err := io.ReadAll(resp.Body) if err != nil { return nil, fmt.Errorf("failed to read response body: %w", err) } return body, nil }cmd/zetae2e/config/clients.go (1)
127-140: Approve with a minor suggestion.The
getTONClientfunction is well-implemented. It correctly retrieves the TON configuration from the specified URL using thetonconfig.ConfigFromURLfunction and creates a new TON client using the retrieved configuration. The use of a retry mechanism ensures robustness in handling potential delays in the sidecar bootstrapping process.One minor suggestion:
Consider updating the error message to provide more context about the failure:
-return nil, fmt.Errorf("failed to get ton config: %w", err) +return nil, fmt.Errorf("failed to retrieve TON configuration from %s: %w", configURL, err)This will help in identifying the specific URL that caused the failure when debugging.
e2e/runner/ton/deployer.go (1)
170-187: LGTM, but consider making the function more flexible.The
waitForAccountActivationfunction is correctly implemented and there are no issues. However, the function uses a fixed number of attempts and interval, which may not be sufficient in some cases.Consider using configuration values for the number of attempts and interval to make the function more flexible. For example:
func (d *Deployer) waitForAccountActivation(ctx context.Context, account ton.AccountID, maxAttempts int, interval time.Duration) error { for i := 0; i < maxAttempts; i++ { state, err := d.blockchain.GetAccountState(ctx, account) if err != nil { return err } if state.Account.Status() == tlb.AccountActive { return nil } time.Sleep(interval) } return fmt.Errorf("account %s is not active", account.ToRaw()) }e2e/runner/runner.go (1)
21-21: Carefully evaluate the security and reliability of the external package.The import statement for the
github.com/tonkeeper/tongo/tonpackage is correctly formatted and follows Go's import conventions. However, since this package is imported from an external repository, it's crucial to carefully evaluate its security and reliability before integrating it into the codebase.
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
Files selected for processing (29)
- .github/workflows/e2e.yml (5 hunks)
- Makefile (1 hunks)
- changelog.md (1 hunks)
- cmd/zetae2e/config/clients.go (3 hunks)
- cmd/zetae2e/config/local.yml (2 hunks)
- cmd/zetae2e/config/localnet.yml (1 hunks)
- cmd/zetae2e/init.go (1 hunks)
- cmd/zetae2e/local/local.go (4 hunks)
- cmd/zetae2e/local/ton.go (1 hunks)
- contrib/localnet/docker-compose.yml (9 hunks)
- contrib/localnet/orchestrator/Dockerfile.fastbuild (1 hunks)
- contrib/localnet/orchestrator/start-zetae2e.sh (1 hunks)
- contrib/localnet/scripts/wait-for-ton.sh (1 hunks)
- e2e/config/config.go (1 hunks)
- e2e/e2etests/e2etests.go (2 hunks)
- e2e/e2etests/test_ton_deposit.go (1 hunks)
- e2e/runner/clients.go (2 hunks)
- e2e/runner/logger.go (1 hunks)
- e2e/runner/runner.go (3 hunks)
- e2e/runner/setup_ton.go (1 hunks)
- e2e/runner/ton/accounts.go (1 hunks)
- e2e/runner/ton/accounts_test.go (1 hunks)
- e2e/runner/ton/clients.go (1 hunks)
- e2e/runner/ton/coin.go (1 hunks)
- e2e/runner/ton/deployer.go (1 hunks)
- e2e/runner/ton/gateway.compiled.json (1 hunks)
- go.mod (1 hunks)
- zetaclient/chains/ton/config.go (1 hunks)
- zetaclient/chains/ton/observer/observer_test.go (1 hunks)
Files skipped from review due to trivial changes (1)
- zetaclient/chains/ton/observer/observer_test.go
Additional context used
Path-based instructions (19)
e2e/runner/clients.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/ton/coin.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/ton/config.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/scripts/wait-for-ton.sh (1)
Pattern
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.e2e/e2etests/test_ton_deposit.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/local/ton.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/init.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/setup_ton.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/ton/accounts_test.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/ton/clients.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/config/clients.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/ton/deployer.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/ton/accounts.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/logger.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/orchestrator/start-zetae2e.sh (1)
Pattern
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.e2e/config/config.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/runner.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/local/local.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/e2etests/e2etests.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
GitHub Check: codecov/patch
zetaclient/chains/ton/config.go
[warning] 17-18: zetaclient/chains/ton/config.go#L17-L18
Added lines #L17 - L18 were not covered by tests
[warning] 20-21: zetaclient/chains/ton/config.go#L20-L21
Added lines #L20 - L21 were not covered by tests
[warning] 23-25: zetaclient/chains/ton/config.go#L23-L25
Added lines #L23 - L25 were not covered by tests
[warning] 28-30: zetaclient/chains/ton/config.go#L28-L30
Added lines #L28 - L30 were not covered by tests
[warning] 33-33: zetaclient/chains/ton/config.go#L33
Added line #L33 was not covered by tests
[warning] 35-36: zetaclient/chains/ton/config.go#L35-L36
Added lines #L35 - L36 were not covered by tests
[warning] 39-39: zetaclient/chains/ton/config.go#L39
Added line #L39 was not covered by tests
Gitleaks
e2e/runner/ton/accounts_test.go
16-16: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
cmd/zetae2e/config/local.yml
5-5: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
10-10: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
14-14: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
18-18: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
22-22: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
26-26: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
27-27: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
31-31: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
35-35: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
39-39: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
43-43: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
47-47: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
51-51: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
55-55: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
59-59: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
63-63: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
68-68: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
72-72: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
76-76: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
80-80: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
82-82: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (56)
e2e/runner/clients.go (2)
9-9: LGTM!The import statement follows the standard Go convention and the alias is clear and concise.
22-22: Excellent addition!The new
TONfield in theClientsstruct follows the existing naming convention and type pattern. This change effectively expands the multi-chain capabilities of the codebase, aligning with the PR objectives. Well done!e2e/runner/ton/coin.go (3)
13-18: LGTM!The
TONCoinsfunction is well-implemented, following best practices such as:
- Using a constant for the conversion factor, improving readability and maintainability.
- Providing clear documentation explaining the conversion and the use of the
TONabbreviation.- Adhering to the single responsibility principle by focusing on a specific task.
- Following the Go naming convention for the function name.
The implementation is correct and the function is expressive and clean.
20-22: LGTM!The
UintToCoinsfunction is a simple and clean type conversion frommath.Uinttotlb.Coins. The implementation is correct and the function name is expressive, following the Go naming convention. The function adheres to the single responsibility principle, making it focused and maintainable.
24-27: LGTM!The
FormatCoinsfunction is a clean and straightforward implementation for formatting amath.Uintvalue into a human-friendly string representation of coins. The use of theutils.HumanFriendlyCoinsReprfunction is appropriate for the formatting task. The function name is expressive and follows the Go naming convention. The function is small and focused on a single responsibility, adhering to the principles of clean code.The comment about the type conversion being safe is helpful for code reviewers and maintainers, providing assurance about the correctness of the operation.
contrib/localnet/scripts/wait-for-ton.sh (2)
3-4: LGTM!The variable names are descriptive and the values are reasonable. Defining the variables as constants is a good practice.
35-36: LGTM!The error message is clear and informative. Exiting with a failure status is a good practice for indicating that the script failed.
e2e/runner/setup_ton.go (1)
12-61: LGTM!The
SetupTONfunction is well-structured, follows a clear sequence of steps, and has consistent error handling. The function uses thetonpackage to interact with the TON blockchain and uses thectxvariable to pass the context to the TON client functions. The function also logs important information using ther.Logger.e2e/runner/ton/accounts_test.go (1)
16-16: False positive: The sample TSS private key is not a generic API key.The static analysis tool flagged the sample TSS private key as a potential generic API key. However, this is a false positive because:
- The key is used for testing purposes only and not for accessing any external services.
- The key is hard-coded in the test and not stored in a configuration file or environment variable.
- The test is located in a dedicated testing package, indicating that it's not part of the production code.
Therefore, it's safe to ignore this warning.
Tools
Gitleaks
16-16: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
e2e/runner/ton/gateway.compiled.json (1)
1-5: Skipping review of the compiled JSON file.This file appears to be a compiled JSON configuration for a TON gateway, containing a hash and a hex string representing compiled smart contract code or a cryptographic signature.
Compiled files are typically not reviewed as they are generated artifacts. Without more context about the TON architecture and the specific purpose of this file, it is difficult to provide meaningful review comments.
If this file was included in the PR by mistake, consider removing it from the changeset. If it is required, ensure that the source files used to generate this compiled JSON are also included in the PR for review.
e2e/runner/ton/clients.go (5)
15-18: LGTM!The
Clientstruct is correctly defined, embedding the necessary clients for interacting with the TON blockchain.
47-50: LGTM!The
SidecarClientstruct is correctly defined, encapsulating the necessary fields for interacting with the TON sidecar service.
54-57: LGTM!The
NewSidecarClientfunction is correctly implemented, creating a new instance ofSidecarClientwith the provided base URL and a configured HTTP client.
75-77: LGTM!The
LiteServerURLfunction is correctly implemented, returning the URL to the lite server configuration by appending the path to the base URL.
123-132: LGTM!The
getfunction is correctly implemented, creating a new HTTP GET request with the provided context and sending it using the HTTP client.cmd/zetae2e/config/clients.go (1)
Line range hint
24-74: LGTM!The changes to the
getClientsFromConfigfunction look good. The function correctly initializes the TON client using thegetTONClientfunction if theTONSidecarURLis provided in the configuration. It also follows a consistent error handling pattern and includes the TON client in the returnedrunner.Clientsstructure.cmd/zetae2e/config/localnet.yml (1)
94-94: LGTM!The addition of the
ton_sidecar_urlconfiguration is a positive change that enables integration with the TON sidecar service. The URLhttp://ton:8000correctly points to the sidecar service running in thetoncontainer on port 8000.This configuration will allow the system to communicate with the TON blockchain or utilize TON-related services provided by the sidecar. It enhances the functionality and expands the capabilities of the application to support interactions with the TON network.
e2e/runner/ton/deployer.go (8)
29-52: LGTM!The
NewDeployerconstructor function is well-implemented with appropriate validation checks and error handling. The use oferrors.Wrapto provide additional context to the errors is a good practice.
54-56: LGTM!The
Seqnofunction is correctly implemented and there are no issues.
59-72: LGTM!The
GetBalanceOffunction is well-implemented with appropriate error handling and the use oferrors.Wrapto provide additional context to the errors. Waiting for the account to be activated before retrieving the balance is a good practice.
75-82: LGTM!The
Fundfunction is correctly implemented and there are no issues. Using thesendmethod to send the transaction is a good practice as it handles waiting for confirmation and other necessary steps.
85-99: LGTM!The
Deployfunction is well-implemented with no issues. Using thesendmethod to send the transaction and waiting for the account to be activated after deploying it are good practices.
101-124: LGTM!The
CreateWalletfunction is well-implemented with appropriate error handling and the use oferrors.Wrapto provide additional context to the errors. Double-checking the balance of the created wallet to ensure that it is not zero is a good practice.
126-151: LGTM!The
sendfunction is well-implemented with appropriate error handling and the use oferrors.Wrapto provide additional context to the errors. Waiting for the next sequence number to ensure that the message is confirmed and waiting for blocks if thewaitForBlocksflag is set are good practices.
1-28: LGTM!The type definitions and interface declarations in the file are well-organized and follow Go best practices. The code is correctly implemented and there are no issues.
cmd/zetae2e/config/local.yml (3)
1-5: LGTM!The changes to the
zeta_chain_idanddefault_accountsection look good. Enclosing thebech32_addressin quotes is a minor change for consistency and does not affect the functionality.Tools
Gitleaks
5-5: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
95-96: LGTM!The changes to the RPC configurations look good:
- Modifying the Solana RPC endpoint to point to "http://localhost:8899" suggests a change to use a local instance instead of a named service, which is suitable for local development and testing.
- Adding the
ton_sidecar_urlentry pointing to "http://localhost:8111" indicates the integration of a TON sidecar service running on a local instance, which aligns with the project's requirements.These changes improve the local development and testing environment and do not raise any concerns.
Line range hint
97-120: Skipped review.The
contractssection remains unchanged, so no review comments are necessary.e2e/runner/ton/accounts.go (9)
34-41: LGTM!The function is well-structured and follows the principle of separation of concerns by delegating the wallet construction to
ConstructWalletFromPrivateKey. The error handling is also appropriate.
99-113: LGTM!The function is well-structured and follows the principle of separation of concerns by delegating the state init generation and address generation to separate functions. The error handling is also appropriate.
115-127: LGTM!The function is well-structured and follows the principle of separation of concerns by delegating the retrieval of gateway code and building of gateway data to separate functions. The error handling is also appropriate.
129-148: LGTM!The function is well-structured and handles the retrieval of the gateway code from the embedded JSON correctly. The error handling is also appropriate.
151-178: LGTM!The function is well-structured and handles the building of the gateway data cell correctly. The error handling is also appropriate.
180-188: LGTM!The
errCollectfunction is a useful utility for handling multiple errors. It provides a clean way to collect and return the first encountered error, along with the index at which it occurred.
191-202: LGTM!The
generateStateInitfunction correctly generates atlb.StateInitstruct using the provided code and data cells. The usage oftlb.Maybeandtlb.Reftypes is appropriate.
205-220: LGTM!The
generateAddressfunction correctly generates aton.AccountIDstruct using the provided workchain ID and the hash of the marshaled state init. The error handling is also appropriate.
1-220: Overall, the file is well-structured and follows clean code principles.The functions in this file are correctly implemented and handle the construction and generation of TON accounts and wallets effectively. The code is modular, readable, and maintains appropriate error handling.
Great job on the implementation!
e2e/runner/logger.go (1)
74-88: Excellent improvements to theInfomethod!The changes made to the
Infomethod enhance its clarity, performance, and alignment with modern Go practices:
- Updating the variadic parameter type from
...interface{}to...anyimproves readability and leverages theanyalias introduced in Go 1.18.- The early return when
verboseis false optimizes performance by avoiding unnecessary locking and message formatting.- Streamlining the message formatting logic by unconditionally constructing the formatted log line and performing the logging operation directly simplifies the code and improves readability.
Overall, these updates demonstrate a strong understanding of Go best practices and a focus on writing clean, efficient, and maintainable code.
contrib/localnet/docker-compose.yml (1)
244-258: LGTM! Thetonservice has been properly configured.The addition of the
tonservice to the Docker Compose configuration is a crucial step in integrating the TON blockchain into the localnet environment. The service configuration includes all the necessary components, such as the image, container name, hostname, ports, environment variables, and network settings.By assigning a specific IPv4 address within the
mynetwork, thetonservice can effectively communicate with other services while maintaining proper isolation. This setup ensures a clean and organized localnet environment for testing and development purposes.Overall, the configuration of the
tonservice aligns with the best practices and follows a consistent structure with the other services in the file..github/workflows/e2e.yml (5)
40-40: LGTM!The addition of the
TON_TESTSoutput variable is consistent with the other output variables and is necessary to conditionally run the TON tests.
66-66: LGTM!Setting the
TON_TESTSoutput variable based on the presence of theTON_TESTSlabel is consistent with the conditional logic for other test categories.
94-94: LGTM!Setting the
TON_TESTSoutput variable totruefor scheduled runs ensures that the TON tests are executed as part of the regular testing schedule.
108-108: LGTM!Setting the
TON_TESTSoutput variable based on the presence of theton-testtarget in themake-targetsinput allows for manually triggering the TON tests.
149-151: LGTM!The addition of the job step for running the
start-ton-testtarget is consistent with the other test categories and ensures that the TON tests are executed when the necessary conditions are met.e2e/config/config.go (1)
94-100: LGTM!The addition of the
TONSidecarURLfield to theRPCsstruct is well-implemented and consistent with the existing code. The field name, type, and YAML tag are appropriate and follow the established conventions.e2e/runner/runner.go (1)
75-76: LGTM!The addition of the
TONDeployerandTONGatewayfields to theE2ERunnerstruct is a clear indication of the integration of TON blockchain functionality into the runner. The field names are descriptive and follow Go's naming conventions, making their purpose evident. The types chosen for these fields (*tonrunner.Deployerandton.AccountID) seem appropriate based on their names and the context of interacting with the TON blockchain. The fields are also correctly aligned with the existing struct fields, maintaining a consistent style. Overall, these changes look good and are approved.Makefile (1)
283-286: LGTM!The new
start-ton-testtarget in the Makefile is implemented correctly and aligns with the PR objectives. It enhances the functionality by allowing users to initiate a TON test environment alongside the existing test functionality.cmd/zetae2e/local/local.go (3)
37-37: LGTM!The addition of the
flagTestTONconstant follows the naming convention and is consistent with other test flags.
73-73: LGTM!The
flagTestTONflag is correctly integrated into theNewLocalCmdfunction usingcmd.Flags().Bool(), and the flag description is clear and consistent with other test flags.
103-103: LGTM!The handling of the
testTONflag in thelocalE2ETestfunction is correct:
- The flag value is correctly retrieved using
must(cmd.Flags().GetBool(flagTestTON)).- The
if testTON { ... }block is correctly placed among other test flags.- The block correctly checks if the TON client is initialized and logs an error message if not.
- The
tonTestsslice is defined with the appropriate test names.- The
tonTestRoutineis correctly started usingeg.Go().Also applies to: 385-396
go.mod (3)
339-339: Verify the necessity and security of adding thecf-workers-proxy-enn.pages.dev/oasisprotocol/curve25519-voidependency.Please ensure that:
- This dependency is absolutely necessary for the project's requirements and there are no existing libraries in the project that can fulfill the same purpose.
- The library is actively maintained, has a good track record, and has undergone security audits to ensure its robustness.
Adding new cryptographic dependencies increases the attack surface and complexity of the project, so it's crucial to carefully evaluate the impact before proceeding.
340-340: Justify the necessity of adding thecf-workers-proxy-enn.pages.dev/snksoft/crcdependency.The Go standard library already provides a
hash/crc32package for CRC-32 calculations. Please verify if there are specific requirements that justify the addition of this external CRC package, such as:
- Support for other CRC variants besides CRC-32.
- Specific performance requirements that the standard library package does not meet.
If the existing standard library package suffices, consider removing this external dependency to keep the project lean and maintainable.
341-341: Verify the suitability and maturity of thecf-workers-proxy-enn.pages.dev/tonkeeper/tongodependency.Given that this dependency is crucial for integrating TON blockchain capabilities into the project, please ensure the following:
- The library provides all the necessary functionalities and APIs required for the project's TON integration requirements.
- The chosen version (
v1.9.3) is stable, mature, and compatible with the project's Go version and other dependencies.- The library has good documentation, usage examples, and an active community for support and maintenance.
Careful evaluation of the library's maturity and compatibility is essential to ensure a smooth integration and maintainable codebase.
e2e/e2etests/e2etests.go (2)
56-67: LGTM!The addition of the comment block for the Solana test section improves code organization and readability by clearly delineating the Solana-related tests. The comment style is consistent with the existing codebase.
432-442: LGTM!The addition of the
TestTONDepositNametest case for TON deposits is well-structured and follows the established patterns in the codebase. The test case definition includes a clear description, appropriate argument definition, and is associated with theTestTONDepositfunction. The code organization is maintained by placing the test case under the "TON tests" comment block.changelog.md (1)
39-39: LGTM!The changelog entry concisely captures the addition of the e2e framework for the TON blockchain. This is a valuable enhancement to the project's testing infrastructure.
swift1337
force-pushed
the
feat/ton-localnet
branch
from
3bc7b66 to
3bb0534
Compare
Description
This PR adds containerized TON localnet node with all wiring for local development and E2E testing.
Note that the build is
x86only./statushealthchecklite-client.json: swaplocalhost(encoded as int2130706433) withton's container IP 🪖make start-ton-testtriggered with the label TON_TESTStondocker image to a separate repoUtils
Based on https://github.com/neodix42/MyLocalTon
Closes: #2720
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests