dockerize beacond #1934
dockerize beacond #1934
Conversation
WalkthroughThe recent changes introduce functionality for managing a Docker container for the Changes
Possibly related PRs
Poem
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
CodeRabbit Configuration File (
|
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
nidhi-singh02
force-pushed
the
bartio-docker
branch
from
b92adef
to
40e6b20
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1934 +/- ##
=======================================
Coverage 23.48% 23.48%
=======================================
Files 357 357
Lines 16064 16064
Branches 12 12
=======================================
Hits 3772 3772
Misses 12121 12121
Partials 171 171 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (1)
- build/scripts/testing.mk (1 hunks)
Additional comments not posted (1)
build/scripts/testing.mk (1)
56-62: LGTM! Verifybuild-dockertarget andVERSIONhandling.The logic for checking and building the Docker image is correct.
Ensure that the
build-dockertarget is defined and correctly handles theVERSIONvariable.Run the following script to verify the
build-dockertarget andVERSIONhandling:Verification successful
The
build-dockertarget correctly handles theVERSIONvariable.The
build-dockertarget is defined inbuild/scripts/build.mkand uses theVERSIONvariable as a build argument, confirming that it is handled properly. No further action is needed.
build/scripts/build.mk: Thebuild-dockertarget uses--build-arg GIT_VERSION=$(VERSION).Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence and handling of the `build-docker` target. # Test: Search for the `build-docker` target definition. Expect: A target definition that handles `VERSION`. rg --type make 'build-docker' -A 5Length of output: 1384
Signed-off-by: nidhi-singh02 <trippin@berachain.com>
There was a problem hiding this comment.
Actionable comments posted: 3
Outside diff range comments (6)
mod/node-core/pkg/services/registry/mocks/registry_option.mock.go (1)
Line range hint
14-18: Avoid using panic in mock functionsIn the
Executemethod, the mock panics when no return value is specified:if len(ret) == 0 { panic("no return value specified for Execute") }Using
panicin mocks can cause abrupt test failures and make debugging difficult. Instead, consider returning a default value or an error to handle this case gracefully.Apply this diff to handle the situation without panicking:
func (_m *RegistryOption) Execute(_a0 *service.Registry) error { ret := _m.Called(_a0) - if len(ret) == 0 { - panic("no return value specified for Execute") - } var r0 error if rf, ok := ret.Get(0).(func(*service.Registry) error); ok { r0 = rf(_a0) } else { r0 = ret.Error(0) } return r0 }Alternatively, ensure that all your tests using this mock provide the necessary return values to avoid triggering the panic.
mod/node-api/backend/mocks/withdrawal_credentials.mock.go (1)
Line range hint
13-17: Consider handling missing return values without panickingIn the
ToExecutionAddressmethod, the code panics if no return value is specified:if len(ret) == 0 { panic("no return value specified for ToExecutionAddress") }Using
paniccan cause abrupt termination during tests, which might not be ideal. Consider configuring Mockery to handle this scenario more gracefully, such as returning zero values or a default error.mod/node-api/backend/mocks/state_processor.mock.go (1)
Line range hint
11-11: Useanyinstead ofinterface{}for type parameter constraints.Since Go 1.18,
anyis an alias forinterface{}. Usinganyimproves code readability and aligns with modern Go conventions.Apply this diff to update the type parameter constraints:
type StateProcessor[BeaconStateT interface{}] struct { mock.Mock } type StateProcessor_Expecter[BeaconStateT interface{}] struct { mock *mock.Mock } // ... -func NewStateProcessor[BeaconStateT interface{}](t interface { +func NewStateProcessor[BeaconStateT any](t interface { mock.TestingT Cleanup(func()) }) *StateProcessor[BeaconStateT] { mock := &StateProcessor[BeaconStateT]{} mock.Mock.Test(t)Also applies to: 14-14, 67-67
mod/node-api/backend/mocks/availability_store.mock.go (2)
Line range hint
10-13: Consider Specifying More Concrete Type ConstraintsThe type parameters
BeaconBlockBodyT interface{}andBlobSidecarsT interface{}are currently defined as empty interfaces. If possible, consider specifying more concrete type constraints to enhance type safety and readability. This can help prevent unintended usage and improve code comprehension.
Line range hint
26-33: Enhance Readability of Type AssertionsThe type assertion logic in the
IsDataAvailablemethod is a bit complex:var r0 bool if rf, ok := ret.Get(0).(func(context.Context, math.U64, BeaconBlockBodyT) bool); ok { r0 = rf(_a0, _a1, _a2) } else { r0 = ret.Get(0).(bool) }Consider simplifying or adding comments to clarify the purpose of this conditional, which would improve maintainability and assist future developers in understanding the code.
mod/node-api/backend/mocks/block_store.mock.go (1)
Line range hint
11-11: Useanyinstead ofinterface{}for type parametersIn Go 1.18 and later,
anyis an alias forinterface{}and is considered more idiomatic. To enhance readability, consider replacinginterface{}withanyin the type parameter constraints.Apply this diff to simplify the code:
-type BlockStore[BeaconBlockT interface{}] struct { +type BlockStore[BeaconBlockT any] struct {Similarly, update the following lines:
-type BlockStore_Expecter[BeaconBlockT interface{}] struct { +type BlockStore_Expecter[BeaconBlockT any] struct { -type BlockStore_GetSlotByBlockRoot_Call[BeaconBlockT interface{}] struct { +type BlockStore_GetSlotByBlockRoot_Call[BeaconBlockT any] struct { -type BlockStore_GetSlotByExecutionNumber_Call[BeaconBlockT interface{}] struct { +type BlockStore_GetSlotByExecutionNumber_Call[BeaconBlockT any] struct { -type BlockStore_GetSlotByStateRoot_Call[BeaconBlockT interface{}] struct { +type BlockStore_GetSlotByStateRoot_Call[BeaconBlockT any] struct { -func NewBlockStore[BeaconBlockT interface{}](t interface { +func NewBlockStore[BeaconBlockT any](t interface {Also applies to: 14-14, 38-38, 87-87, 133-133, 163-163
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (23)
- mod/engine-primitives/pkg/engine-primitives/mocks/blobs_bundle.mock.go (1 hunks)
- mod/engine-primitives/pkg/engine-primitives/mocks/built_execution_payload_env.mock.go (1 hunks)
- mod/engine-primitives/pkg/engine-primitives/mocks/payload_attributer.mock.go (1 hunks)
- mod/node-api/backend/mocks/availability_store.mock.go (1 hunks)
- mod/node-api/backend/mocks/beacon_block_header.mock.go (1 hunks)
- mod/node-api/backend/mocks/beacon_state.mock.go (1 hunks)
- mod/node-api/backend/mocks/block_store.mock.go (1 hunks)
- mod/node-api/backend/mocks/deposit_store.mock.go (1 hunks)
- mod/node-api/backend/mocks/node.mock.go (1 hunks)
- mod/node-api/backend/mocks/state_processor.mock.go (1 hunks)
- mod/node-api/backend/mocks/storage_backend.mock.go (1 hunks)
- mod/node-api/backend/mocks/validator.mock.go (1 hunks)
- mod/node-api/backend/mocks/withdrawal.mock.go (1 hunks)
- mod/node-api/backend/mocks/withdrawal_credentials.mock.go (1 hunks)
- mod/node-core/pkg/services/registry/mocks/basic.mock.go (1 hunks)
- mod/node-core/pkg/services/registry/mocks/dispatcher.mock.go (1 hunks)
- mod/node-core/pkg/services/registry/mocks/registry_option.mock.go (1 hunks)
- mod/primitives/pkg/crypto/mocks/bls_signer.mock.go (1 hunks)
- mod/storage/pkg/interfaces/mocks/db.mock.go (1 hunks)
- mod/storage/pkg/pruner/mocks/beacon_block.mock.go (1 hunks)
- mod/storage/pkg/pruner/mocks/block_event.mock.go (1 hunks)
- mod/storage/pkg/pruner/mocks/prunable.mock.go (1 hunks)
- mod/storage/pkg/pruner/mocks/pruner.mock.go (1 hunks)
Additional comments not posted (22)
mod/storage/pkg/pruner/mocks/beacon_block.mock.go (1)
1-1: Mock generation updated to mockery v2.46.0The mock file has been regenerated using mockery v2.46.0. This ensures that the mocks are up-to-date with the latest version of the tool.
mod/node-core/pkg/services/registry/mocks/dispatcher.mock.go (1)
1-1: Mock file regenerated with mockery v2.46.0The mock file has been updated using mockery v2.46.0. This ensures that the mocks are in sync with the latest version of the tool.
mod/storage/pkg/pruner/mocks/prunable.mock.go (1)
1-1: Mockery version update to v2.46.0 is acceptable.The file has been regenerated using mockery v2.46.0. The update is appropriate, and no issues are found with the generated code.
mod/node-core/pkg/services/registry/mocks/registry_option.mock.go (1)
1-1: Mockery version update to v2.46.0The mock file has been regenerated using mockery v2.46.0, which is acceptable. Ensure that the mockery tool version is consistent across the project to prevent version mismatches.
mod/node-api/backend/mocks/node.mock.go (1)
1-1: Mockery version updated to v2.46.0.The mock file has been regenerated using
mockery v2.46.0, updating from the previous version. This ensures that the mocks are up-to-date with the latest generation tool. Please confirm that all contributors are using the same version ofmockeryto maintain consistency in the generated code.mod/node-api/backend/mocks/withdrawal.mock.go (1)
1-1: Ensure consistent mockery versions across all mock filesThe mock file has been regenerated using mockery v2.46.0. To maintain consistency across the codebase, please verify that all mock files are generated with the same version of mockery. This helps prevent potential discrepancies or incompatibilities between mocks.
Run the following script to check for inconsistencies in mockery versions across all mock files:
Verification successful
Remove unused 'old_pruner.mock.go' file and confirm mockery version consistency
The 'old_pruner.mock.go' file appears to be unused in the codebase and is not tracked by git. To maintain a clean codebase and avoid confusion:
- Remove the 'old_pruner.mock.go' file from the root directory.
- Confirm that all other mock files are using mockery v2.46.0, which is consistent across the codebase.
- Consider implementing a process to ensure all mock files are generated with the same mockery version in future development.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for consistent mockery versions across all mock files. # Expected result: All mock files should report the same mockery version. rg --files-with-matches '// Code generated by mockery v' -g '*.go' | while read -r file; do version=$(grep -oP 'mockery v[\d\.]+' "$file") echo "$file: $version" done | sort | uniq -cLength of output: 6964
Script:
#!/bin/bash # Description: Check if old_pruner.mock.go is imported or used in the codebase # Search for imports of old_pruner.mock.go echo "Searching for imports of old_pruner.mock.go:" rg -i 'import.*old_pruner\.mock' # Search for usage of OldPrunerMock (assuming the mock struct name follows convention) echo -e "\nSearching for usage of OldPrunerMock:" rg -i 'OldPrunerMock' # Check if the file is tracked by git echo -e "\nChecking if old_pruner.mock.go is tracked by git:" git ls-files | grep 'old_pruner\.mock\.go'Length of output: 406
mod/node-api/backend/mocks/withdrawal_credentials.mock.go (1)
1-1: Approved: Mockery version updated to v2.46.0The mock has been regenerated using Mockery version 2.46.0. This keeps the mocks up to date with the latest tool improvements.
mod/node-core/pkg/services/registry/mocks/basic.mock.go (1)
1-1: Verify consistency ofmockeryversions across all mocksThe mock file has been regenerated using
mockery v2.46.0. To ensure consistency across the codebase, please verify that all mock files are generated with the same version.Run the following script to check the versions of
mockeryused in all mock files:This script lists all instances of the
mockeryversion comment in mock files and counts the occurrences of each version. The expected result is that all mocks should report// Code generated by mockery v2.46.0. DO NOT EDIT.Verification successful
Mockery version consistency verified across all mocks
The verification process has confirmed that all 23 mock files in the codebase are generated using mockery v2.46.0. This ensures consistency across the project, as requested in the review comment.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check the mockery version used in all generated mock files # Search for the mockery version comment in all Go files ending with 'mock.go' rg '^// Code generated by mockery v' --type go -g '*mock.go' --no-filename | sort | uniq -cLength of output: 152
mod/storage/pkg/pruner/mocks/pruner.mock.go (1)
1-1: Verify the impact of updating mockery to v2.46.0The mock file has been regenerated using
mockeryversion v2.46.0. Upgrading the mock generation tool may introduce subtle changes in the generated code. Please ensure that the updated mocks behave as expected and do not introduce any unintended side effects in your tests.You can run the following script to compare the previous and current versions of the generated mock:
This script will highlight any differences between the two versions, allowing you to review any changes introduced by the new
mockeryversion.Verification successful
Mockery update to v2.46.0 verified as safe
The update from mockery v2.45.1 to v2.46.0 has been verified and appears to be safe. The changes are minimal:
- Only the version number in the comment has been updated in the mock file.
- No structural changes were made to the generated mock.
- The mockery v2.46.0 release notes indicate minor improvements without breaking changes.
- No test files were found that directly use this mock, reducing the risk of unintended side effects.
This update is unlikely to introduce any issues in your tests or codebase.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Compare the previous and current generated mocks for unintended changes. # Fetch the previous version of the mock file git show HEAD~1:mod/storage/pkg/pruner/mocks/pruner.mock.go > old_pruner.mock.go # Compare the old and new mock files diff old_pruner.mock.go mod/storage/pkg/pruner/mocks/pruner.mock.goLength of output: 245
Script:
#!/bin/bash # Search for other mock files in the project echo "Other mock files in the project:" fd -e mock.go # Look for mockery changelog or release notes echo -e "\nMockery v2.46.0 release notes:" curl -s https://api.github.com/repos/vektra/mockery/releases/tags/v2.46.0 | jq -r '.body' # Find test files that might use the pruner mock echo -e "\nTest files that might use the pruner mock:" rg -l "mock_Pruner" --type goLength of output: 1808
mod/engine-primitives/pkg/engine-primitives/mocks/blobs_bundle.mock.go (1)
1-1: Mock file regenerated with mockery v2.46.0The mock file
blobs_bundle.mock.gohas been updated using mockery versionv2.46.0. This ensures that the mocks are generated with the latest improvements and bug fixes from the tool.mod/primitives/pkg/crypto/mocks/bls_signer.mock.go (1)
1-1: Updated mock generated with mockery v2.46.0The mock file has been regenerated using mockery v2.46.0. Ensure that all team members use the same version of mockery to avoid unnecessary diffs in generated files.
mod/node-api/backend/mocks/availability_store.mock.go (3)
Line range hint
19-24: Confirm Acceptability of Panic in Mock MethodIn the
IsDataAvailablemethod, if no return value is specified, the function will panic:if len(ret) == 0 { panic("no return value specified for IsDataAvailable") }Ensure that this behavior is acceptable within your testing framework and won't cause unintended side effects during test execution.
Line range hint
81-89: Ensure Correct Implementation of Testing InterfaceThe
NewAvailabilityStorefunction expects a testing interface that includesmock.TestingTand aCleanup(func())method:func NewAvailabilityStore[BeaconBlockBodyT interface{}, BlobSidecarsT interface{}](t interface { mock.TestingT Cleanup(func()) }) *AvailabilityStore[BeaconBlockBodyT, BlobSidecarsT] { // ... }Verify that this matches the testing interfaces used in your project. In some versions of the testing framework,
Cleanupmight not be available or may differ. Adjust accordingly to ensure compatibility.
1-1: Verify Compatibility with Updated Mockery VersionThe mock implementation has been regenerated using
mockeryv2.46.0, updated from v2.45.1. Ensure that this new version does not introduce any breaking changes or unexpected behavior in your tests.Run the following script to compare the old and new mock files for any significant differences:
Verification successful
Mockery v2.46.0 Update Verified
The update from Mockery v2.45.1 to v2.46.0 appears to be safe and compatible with your existing codebase. The changelog indicates only minor changes, and the generated mock file structure and content are consistent with typical Mockery-generated mocks. No breaking changes or unexpected behavior were identified.
- The mock file is correctly generated using generics and includes all necessary components.
- The changes in v2.46.0 (documentation updates and config file name propagation) do not affect the generated mock's functionality.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Compare generated mock files between mockery v2.45.1 and v2.46.0. # Assuming you have the previous version of the mocks in a directory named 'old_mocks'. diff -r old_mocks/ mod/node-api/backend/mocks/Length of output: 92
Script:
#!/bin/bash # Description: Gather information about Mockery v2.46.0 and examine the current mock file # Search for Mockery v2.46.0 release notes echo "Searching for Mockery v2.46.0 release notes:" gh release view v2.46.0 --repo vektra/mockery echo "\n--- Mock file content ---" cat mod/node-api/backend/mocks/availability_store.mock.go echo "\n--- Mock file structure ---" grep -n "^type\|^func\|^var" mod/node-api/backend/mocks/availability_store.mock.goLength of output: 8770
mod/node-api/backend/mocks/deposit_store.mock.go (1)
1-1: Mock file regenerated with updated mockery versionThe mock has been regenerated using
mockery v2.46.0. This ensures the mocks are up-to-date with the latest version.mod/storage/pkg/pruner/mocks/block_event.mock.go (1)
1-1: Ensure consistency of mockery versions across all mock filesThe mock file has been regenerated using mockery v2.46.0. Please ensure that all mock files are updated to use the same version to maintain consistency across the codebase.
You can run the following script to identify mock files generated with different versions of mockery:
Verification successful
Mockery versions are consistent across all mock files
The verification process has confirmed that all 23 mock files in the codebase are generated using mockery v2.46.0, which is the expected version. There are no inconsistencies or different versions detected. The codebase maintains uniformity in terms of mockery versions used for mock generation.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all Go mock files and list their mockery versions. # Expected: All mock files should indicate they are generated by mockery v2.46.0 rg '^// Code generated by mockery v' --type go --no-filename | sort | uniq -cLength of output: 138
mod/node-api/backend/mocks/validator.mock.go (1)
1-1: Update to mockery version v2.46.0The mock generation tool has been updated from
v2.45.1tov2.46.0. Please verify that this change does not introduce any unintended modifications to the generated mocks.Run the following script to compare the generated mocks with the main branch:
Verification successful
Mockery update verified: No unintended changes
The update to mockery version v2.46.0 has been verified. The only change in the generated mock files is the version number in the comment at the top of each file, updating from v2.45.1 to v2.46.0. This modification is expected and does not affect the functionality of the mocks.
- All changes are limited to the first comment line in each mock file.
- No other modifications to the mock implementations were detected.
This update is safe and does not require further manual verification.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Compare the generated mocks with those in the main branch to identify any changes beyond the version comment. # Fetch the latest main branch git fetch origin main # Test: Show differences in mock files. Expectation: Only version comments should differ. git diff origin/main -- 'mod/**/mocks/*.go'Length of output: 9648
Script:
#!/bin/bash # Description: Count the number of changed lines in each mock file, excluding the first line # Fetch the latest main branch git fetch origin main # Get the list of changed mock files changed_files=$(git diff --name-only origin/main -- 'mod/**/mocks/*.go') # Initialize a flag to track if any file has changes beyond the first line changes_beyond_first_line=false # Loop through each changed file for file in $changed_files; do # Count the number of changed lines, excluding the first line changed_lines=$(git diff origin/main -- "$file" | tail -n +6 | grep -E '^\+|-' | wc -l) # If there are any changed lines beyond the first, print the file and set the flag if [ "$changed_lines" -gt 0 ]; then echo "File $file has $changed_lines changed lines beyond the first line" changes_beyond_first_line=true fi done # If no files have changes beyond the first line, print a confirmation message if [ "$changes_beyond_first_line" = false ]; then echo "Confirmed: All changes are limited to the first line (version update) in each file" fiLength of output: 11438
Script:
#!/bin/bash # Description: Display the actual changes in a sample mock file, excluding the first line # Choose a sample file sample_file="mod/node-api/backend/mocks/validator.mock.go" # Display the diff for the sample file, excluding the first line echo "Changes in $sample_file (excluding the first line):" git diff origin/main -- "$sample_file" | tail -n +6Length of output: 442
mod/node-api/backend/mocks/block_store.mock.go (1)
1-1: Update to mockery v2.46.0The mocks have been regenerated using mockery v2.46.0. Please ensure that this version is compatible with the project's dependencies and that the generated mocks function as expected.
mod/engine-primitives/pkg/engine-primitives/mocks/built_execution_payload_env.mock.go (1)
1-1: Approved: Update of mockery tool versionThe update from mockery v2.45.1 to v2.46.0 is acceptable and does not introduce any issues.
mod/node-api/backend/mocks/storage_backend.mock.go (1)
1-1: Mock regenerated with updated mockery versionThe mock file has been regenerated using
mockery v2.46.0, ensuring that it includes the latest features and fixes from the tool. This helps maintain consistency across the codebase.mod/node-api/backend/mocks/beacon_block_header.mock.go (1)
1-1: Verify that updating to mockery v2.46.0 introduces no unintended changesThe mock file has been regenerated using mockery v2.46.0. While the update is expected, it's important to ensure that no unintended modifications have been introduced in the generated mocks due to the change in the tool version.
Run the following script to compare the regenerated mock with the previous version:
Verification successful
To ensure that the update to mockery v2.46.0 has not introduced any unintended changes across all mock files, let's check for other modified mock files and verify their changes.
Update to mockery v2.46.0 is safe and introduces no unintended changes
After a thorough examination of all modified mock files, we can confirm that the update to mockery v2.46.0 has been applied consistently and correctly across the codebase. The only change in each file is the version number update in the comment at the top of the file, from v2.45.1 to v2.46.0. No other modifications were found in any of the mock files.
This update appears to be a minor version change, which typically implies backwards compatibility and minimal risk. The consistency of changes across all affected files further supports the conclusion that this update is safe and has not introduced any unintended modifications to the generated mocks.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Compare the regenerated mocks with the previous version to check for unintended changes. # Expected result: Only the comment line indicating the mockery version should differ. # Navigate to the repository root cd "$(git rev-parse --show-toplevel)" # Compare the mock file with its version in the previous commit git diff HEAD~1 -- mod/node-api/backend/mocks/beacon_block_header.mock.goLength of output: 548
Script:
#!/bin/bash # Description: Check for other modified mock files and verify their changes # Expected result: Only the mockery version comment should differ in all modified mock files # Navigate to the repository root cd "$(git rev-parse --show-toplevel)" # Find all modified mock files modified_mocks=$(git diff --name-only HEAD~1 | grep 'mocks/.*\.mock\.go$') # Loop through modified mock files and show their diffs for file in $modified_mocks; do echo "Checking file: $file" git diff HEAD~1 -- "$file" | grep -v '^@@' | grep -v '^index' echo "------------------------" doneLength of output: 17732
mod/node-api/backend/mocks/beacon_state.mock.go (1)
1-1: Update in code generation tool version is acceptableThe mock file
beacon_state.mock.gohas been regenerated using mockeryv2.46.0, updated fromv2.45.1. This ensures that the mocks are up to date with the latest version of the tool.
mod/engine-primitives/pkg/engine-primitives/mocks/payload_attributer.mock.go
Outdated
Show resolved
Hide resolved
| start \ | ||
| --home "./.tmp/beacond" \ | ||
| --pruning=nothing \ | ||
| --api.enable \ |
Summary by CodeRabbit
beacondservice, simplifying the build process.beacondDocker container with configurable options for deployment and testing.These enhancements streamline the deployment and testing experience for users leveraging containerization.