chore: improve localnet build performance

[gartnera]

Description

• Don't use a timestamp if dirty build. Doing this forced unconditional rebuilds every run.
• Don't copy the git directory into the build. This requires that we also provide a way to push the version info into the build.

With this change you should be able to run make start-e2e-test and if nothing has changed zetanode should not be rebuilt.

I could also be convinced that the localnet build should always just be static. Like v22.0.0-next or something like that.

Summary by CodeRabbit

• New Features

  • Enhanced versioning logic in the version.sh script, providing more detailed version information including short commit hashes.

• Improvements

  • Docker build process optimized with new arguments for version control.
  • Streamlined handling of legacy versions in Dockerfile.

• Bug Fixes

  • Adjusted output format for versioning in version.sh to include commit details for both dirty and non-dirty builds.

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

Walkthrough

The pull request introduces significant modifications across several files, primarily focusing on the Docker and Makefile configurations. Key changes include the introduction of new versioning arguments (NODE_VERSION, NODE_COMMIT, OLD_VERSION, and BUILDARCH) in the Dockerfile, updates to the Makefile for tracking these new variables, and enhancements to the versioning logic in the version.sh script. The .dockerignore file has also been adjusted to improve the build process by ignoring unnecessary files and directories.

Changes

Files	Change Summary
.dockerignore	Added .git to ignore list; removed localnet, package.json, yarn.lock, .github/, .gitignore, and dist/**; excluded Dockerfile entries from ignore list.
Dockerfile-localnet	Introduced NODE_VERSION, NODE_COMMIT, OLD_VERSION, and BUILDARCH arguments; organized build stages for modularity; included legacy build options.
Makefile	Replaced VERSION and COMMIT with NODE_VERSION and NODE_COMMIT; updated ldflags to reflect new variables; modified zetanode target for Docker build args.
version.sh	Added conditional check for NODE_VERSION; modified output format for version strings to include short commit hash; improved logic for dirty and non-dirty builds.

Possibly related PRs

• chore: use v19 binaries in upgrade tests #2689: The changes in the Makefile to update the OLD_VERSION argument to NODE_VERSION and NODE_COMMIT are directly related to the modifications made in the main PR, which also introduced these new arguments in the Dockerfile and Makefile.

Suggested labels

UPGRADE_IMPORT_MAINNET_TESTS

Suggested reviewers

• lumtis
• skosito
• kingpinXD
• brewmaster012
• fbac
• swift1337

---

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?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (4)

version.sh (3)

3-8: Approve the addition of NODE_VERSION check with a minor suggestion.

The new conditional check for NODE_VERSION is a valuable addition. It enhances performance and maintainability by allowing version determination without git operations, which is particularly useful for Docker builds.

Consider adding input validation for NODE_VERSION to ensure it's not empty or malformed:

 if [[ -n $NODE_VERSION ]]; then
+    if [[ ! $NODE_VERSION =~ ^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?$ ]]; then
+        echo "Error: NODE_VERSION is not in a valid semantic versioning format" >&2
+        exit 1
+    fi
     echo $NODE_VERSION
     exit
 fi

This change would improve robustness by ensuring NODE_VERSION adheres to semantic versioning format before using it.

---

19-22: Approve the enhancement of version string with a suggestion for clarity.

The addition of the short commit hash to the version string is a commendable improvement. It provides more detailed version information, which enhances traceability and debugging capabilities.

To improve clarity and maintainability, consider using more descriptive variable names:

-commit_timestamp=$(git show --no-patch --format=%at)
-short_commit=$(git rev-parse --short HEAD)
+commit_unix_timestamp=$(git show --no-patch --format=%at)
+short_commit_hash=$(git rev-parse --short HEAD)

This change makes the purpose of each variable immediately clear to future maintainers.

---

25-25: Approve the modified version string output with a suggestion for consistency.

The changes to the version string output for both dirty and non-dirty builds are beneficial. They provide more detailed and consistent version information, which is crucial for debugging and tracking builds.

To maintain consistency with semantic versioning and improve readability, consider restructuring the version string:

-echo "0.0.${commit_timestamp}-${short_commit}-dirty"
+echo "0.0.0-${commit_timestamp}.${short_commit}.dirty"

-echo "0.0.${commit_timestamp}-${short_commit}"
+echo "0.0.0-${commit_timestamp}.${short_commit}"

This format aligns better with semantic versioning principles and improves parsing consistency.

Also applies to: 29-29

Makefile (1)

236-236: Incorporation of version information in Docker build

The addition of NODE_VERSION and NODE_COMMIT as build arguments in the Docker build command is a positive change, aligning with the improved versioning strategy. However, the line length could be reduced for better readability.

Consider breaking the long command into multiple lines for improved readability:

-	$(DOCKER) build -t zetanode --build-arg NODE_VERSION=$(NODE_VERSION) --build-arg NODE_COMMIT=$(NODE_COMMIT) --target latest-runtime -f ./Dockerfile-localnet .
+	$(DOCKER) build -t zetanode \
+		--build-arg NODE_VERSION=$(NODE_VERSION) \
+		--build-arg NODE_COMMIT=$(NODE_COMMIT) \
+		--target latest-runtime \
+		-f ./Dockerfile-localnet .

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 2892114 and e4c1cb4.

📒 Files selected for processing (4)

• .dockerignore (1 hunks)
• Dockerfile-localnet (1 hunks)
• Makefile (3 hunks)
• version.sh (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

version.sh (1)

Pattern **/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.

🔇 Additional comments (5)

.dockerignore (3)

7-7: Commendable addition of .git to the ignore list.

This change aligns with the PR objective of not copying the git directory into the build. It will significantly reduce the size of the build context and improve build performance.

---

Line range hint 9-13: Appropriate exclusion of Dockerfile and docker-compose files.

Excluding Dockerfile and docker-compose files from the Docker build context is a good practice. These files are not needed inside the Docker build and their exclusion can help reduce the build context size.

---

Line range hint 1-6: Verify the necessity of including previously ignored files.

The removal of localnet, package.json, yarn.lock, .github/, .gitignore, and dist/** from the ignore list may increase the build context size and potentially impact build performance. Please confirm that these files are essential for the build process or need to be included in the final image.

✅ Verification successful

Verified: Essential Files Necessary for Build Process

The removed .dockerignore entries (localnet, package.json, yarn.lock, .github/, .gitignore, and dist/**) are essential for the build process as they are actively used in Dockerfiles and build scripts. Their inclusion ensures proper Docker image construction and build functionality.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if the removed ignore entries are used in the Dockerfile or build process

# Test 1: Check Dockerfile for usage of previously ignored files
echo "Checking Dockerfile for usage of previously ignored files:"
rg -i -e "localnet|package.json|yarn.lock|\.github|\.gitignore|dist" Dockerfile*

# Test 2: Check if these files exist in the repository
echo "Checking if previously ignored files exist in the repository:"
fd -H "localnet|package.json|yarn.lock|\.github|\.gitignore|dist"

# Test 3: Check if these files are used in any build scripts
echo "Checking build scripts for usage of previously ignored files:"
rg -i -e "localnet|package.json|yarn.lock|\.github|\.gitignore|dist" *.sh Makefile

Length of output: 4358

Makefile (2)

4-5: Improved version and commit management

The introduction of NODE_VERSION and NODE_COMMIT variables enhances the flexibility and consistency of version management in the build process. The use of ./version.sh for NODE_VERSION and the fallback mechanism for NODE_COMMIT are particularly noteworthy improvements.

---

20-21: Consistent application of new versioning variables

The ldflags have been updated to use NODE_VERSION and NODE_COMMIT, ensuring consistency with the newly introduced variables. This change maintains coherence in version information across different parts of the build process.

Also applies to: 23-24