Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update devcontainer image: v1.0.0 #2678

Merged
merged 1 commit into from
Nov 11, 2024
Merged

Update devcontainer image: v1.0.0 #2678

merged 1 commit into from
Nov 11, 2024

Conversation

tarrencev
Copy link
Contributor

@tarrencev tarrencev commented Nov 11, 2024

Automated changes by create-pull-request GitHub action

Summary by CodeRabbit

  • New Features

    • Updated Docker image to stable version v1.0.0 across multiple workflows, ensuring a more reliable environment for builds and tests.
  • Enhancements

    • Improved CI process with new artifact management and process validation steps for better reliability during testing and deployment.
  • Bug Fixes

    • Resolved potential issues by transitioning from the release candidate version to a stable Docker image.

Copy link

coderabbitai bot commented Nov 11, 2024

Walkthrough

Ohayo, sensei! This pull request primarily updates the Docker image version across multiple configuration files. The image has been changed from a release candidate version (v1.0.0-rc.2) to a stable version (v1.0.0). This change is reflected in the .devcontainer/devcontainer.json, CI workflows, and other related workflows, ensuring a consistent environment for development and testing. Additionally, some workflows have been enhanced with new steps for artifact management and process validation.

Changes

File Change Summary
.devcontainer/devcontainer.json Updated image from v1.0.0-rc.2 to v1.0.0.
.github/workflows/bench.yml Updated image for jobs bench-katana and bench-sozo from v1.0.0-rc.2 to v1.0.0.
.github/workflows/ci.yml Updated image across multiple jobs from v1.0.0-rc.2 to v1.0.0; added steps for artifact management and process validation.
.github/workflows/release-dispatch.yml Updated image in propose-release job from v1.0.0-rc.2 to v1.0.0.

Possibly related PRs

Suggested reviewers

  • glihm

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
🪧 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.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (1)
.github/workflows/ci.yml (1)

Line range hint 89-101: Consider enhancing the Katana process validation.

While the current validation is good, we could make it more robust:

Consider this enhanced version:

- ./katana &
- KATANA_PID=$!
- sleep 2
- if ! kill -0 $KATANA_PID; then
-   echo "Katana exited with an error"
-   exit 1
- fi
- kill $KATANA_PID
+ timeout_seconds=30
+ ./katana &
+ KATANA_PID=$!
+ 
+ # Wait for process to be ready with timeout
+ elapsed=0
+ while [ $elapsed -lt $timeout_seconds ]; do
+   if ! kill -0 $KATANA_PID 2>/dev/null; then
+     echo "Katana failed to start"
+     exit 1
+   fi
+   # Add health check if available
+   # curl --silent --fail http://localhost:PORT/health && break
+   sleep 2
+   elapsed=$((elapsed + 2))
+ done
+ 
+ if [ $elapsed -ge $timeout_seconds ]; then
+   echo "Timeout waiting for Katana to be ready"
+   kill $KATANA_PID
+   exit 1
+ fi
+ 
+ kill $KATANA_PID

This version includes:

  • Configurable timeout
  • Continuous health checking
  • More detailed error messages
🧰 Tools
🪛 actionlint

32-32: label "ubuntu-latest-32-cores" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-14.0", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-13.0", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "macos-12.0", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file

(runner-label)

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 74280d4 and a7b8924.

📒 Files selected for processing (4)
  • .devcontainer/devcontainer.json (1 hunks)
  • .github/workflows/bench.yml (2 hunks)
  • .github/workflows/ci.yml (7 hunks)
  • .github/workflows/release-dispatch.yml (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • .github/workflows/bench.yml
🔇 Additional comments (5)
.github/workflows/release-dispatch.yml (1)

17-17: Ohayo sensei! The Docker image update looks good!

The upgrade from v1.0.0-rc.2 to the stable v1.0.0 version is a positive change that should bring improved stability to the release process. This change aligns well with the updates across other workflow files and the devcontainer configuration.

Let's verify the image version consistency across other files:

✅ Verification successful

Ohayo sensei! The Docker image version is perfectly consistent across all workflows!

The verification shows that:

  • No traces of the old v1.0.0-rc.2 version remain in any workflow files
  • The new stable v1.0.0 version is consistently used across all workflow files:
    • release-dispatch.yml
    • ci.yml
    • bench.yml
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining references to the old RC version
# and confirm consistency of the new version across all workflow files

echo "Checking for any remaining references to v1.0.0-rc.2..."
rg "v1.0.0-rc.2" .github/workflows/

echo "Verifying consistency of v1.0.0 across workflow files..."
rg "ghcr.io/dojoengine/dojo-dev:v1.0.0" .github/workflows/

Length of output: 1088

.devcontainer/devcontainer.json (2)

5-5: Ohayo sensei! Let's verify the Docker image availability.

The update from rc.2 to stable version looks good! However, let's ensure the image is properly published.

✅ Verification successful

Ohayo sensei! The Docker image is properly published and tagged!

The v1.0.0 image exists in the GitHub Container Registry (ghcr.io) and is also marked as latest, indicating it's the current recommended version. The image was published on November 11, 2024, and is readily accessible.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify that the Docker image exists and is accessible
# Expected: Should return details about the v1.0.0 image

gh api \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  /orgs/dojoengine/packages/container/dojo-dev/versions \
  | jq '.[] | select(.metadata.container.tags[] == "v1.0.0")'

Length of output: 810


5-5: Check for breaking changes between rc.2 and stable.

Since this is a transition from a release candidate to a stable version, it would be good to verify if there are any breaking changes that developers should be aware of.

✅ Verification successful

Let me check the changelog between rc.2 and v1.0.0 in more detail to identify any breaking changes.


No breaking changes found between rc.2 and stable v1.0.0

Ohayo sensei! After reviewing the changes between v1.0.0-rc.2 and v1.0.0, I can confirm that there are no breaking changes. The release primarily includes:

  • CLI improvements to match Katana's interface
  • Bug fixes for configuration and logging
  • Minor improvements to tooling

The transition from rc.2 to stable v1.0.0 was smooth with only refinements and no backwards-incompatible changes.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Look for changelog or release notes
# Expected: Should find documentation about changes between rc.2 and v1.0.0

# Check common locations for changelog
fd -g 'CHANGELOG*' -g 'RELEASES*' -g 'BREAKING*'

# Check release notes in GitHub releases
gh release view v1.0.0 2>/dev/null || echo "No release notes found for v1.0.0"

Length of output: 1330


Script:

#!/bin/bash
# Get detailed commit information between rc.2 and v1.0.0
gh pr view 2676 --json body,comments

# Check for any breaking changes or migration guides in docs
fd -t f . | rg -i "migration|upgrade|breaking"

Length of output: 15838

.github/workflows/ci.yml (2)

Line range hint 13-23: Ohayo sensei! Excellent artifact management implementation.

The new artifact management approach with dedicated bins directory and proper upload/download steps is well-structured and follows best practices.

🧰 Tools
🪛 actionlint

32-32: label "ubuntu-latest-32-cores" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-14.0", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-13.0", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "macos-12.0", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file

(runner-label)


34-34: Ohayo! Verify Docker image version consistency across all jobs.

The update from RC to stable version (v1.0.0) looks good! However, let's ensure we haven't missed any jobs that should be using this image.

Also applies to: 59-59, 126-126, 142-142, 157-157, 166-166, 175-175

✅ Verification successful

Ohayo! All Docker image versions are perfectly aligned, sensei!

After checking all workflow files, I can confirm that all jobs are consistently using ghcr.io/dojoengine/dojo-dev:v1.0.0. The only exceptions are in devcontainer.yml which dynamically sets the version using a variable, which is the expected behavior for that workflow.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify Docker image version consistency across all workflow files
# Expected: All references should use v1.0.0

echo "Checking for any remaining RC versions or inconsistent versions:"
rg -g '*.yml' -g '*.yaml' 'ghcr.io/dojoengine/dojo-dev:' .github/workflows/

Length of output: 1359

Copy link

codecov bot commented Nov 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 57.57%. Comparing base (74280d4) to head (a7b8924).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2678      +/-   ##
==========================================
- Coverage   57.58%   57.57%   -0.02%     
==========================================
  Files         404      404              
  Lines       51139    51139              
==========================================
- Hits        29448    29442       -6     
- Misses      21691    21697       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@glihm glihm merged commit 81e9707 into main Nov 11, 2024
13 of 14 checks passed
@glihm glihm deleted the bump-devcontainer branch November 11, 2024 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants