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

ci: switch release workflow to github runners #2346

Merged
merged 9 commits into from
Nov 25, 2024
Merged

ci: switch release workflow to github runners #2346

merged 9 commits into from
Nov 25, 2024

Conversation

shumkov
Copy link
Member

@shumkov shumkov commented Nov 22, 2024

Issue being fixed or feature implemented

Release workflow is still using self-hosted runners.

What was done?

  • Switched runners to ubuntu-24.4
  • Use QEMU for arm builds
  • Fix Dockerfile for release

How Has This Been Tested?

Releasing from this branch

Breaking Changes

None

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
  • I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

  • I have assigned this pull request to a milestone

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features
    • Updated Docker image build and publish workflow for improved runner configurations.
    • Added functionality to create and push a manifest list for better image management.
    • Introduced QEMU setup for cross-platform builds on linux/arm64.
    • Enhanced build process for Rust dependencies using cargo chef.
    • Improved caching mechanisms for dependencies in the build process.
    • Streamlined the build stages for better clarity and efficiency.

Copy link
Contributor

coderabbitai bot commented Nov 22, 2024

Walkthrough

The pull request updates the GitHub Actions workflow for building and publishing Docker images. It modifies the runner configurations to use specific operating systems and versions, replacing previous self-hosted definitions. Additionally, a new step is introduced in the build-image job to set up QEMU for cross-platform builds, and another step in the publish-manifest job to create and push a manifest list using Docker Buildx. Overall, these changes aim to enhance the image management process while maintaining the existing workflow structure.

Changes

File Path Change Summary
.github/workflows/release-docker-image.yml Updated runner configurations to ubuntu-24.04 for linux/amd64 and linux/arm64, added a step for QEMU setup, and introduced a step for manifest list creation using Docker Buildx.
Dockerfile Removed conditional logic for the RELEASE variable, reorganized build stages, improved caching mechanisms, and clarified dependency management in the build process.

Possibly related PRs

  • ci: prebuild dev containers #2184: The changes in the main PR regarding Docker image workflows are related to the introduction of a new workflow for prebuilding development containers, which also involves Docker image management.
  • ci: prebuilt librocksdb in docker image #2318: This PR focuses on optimizing the Docker image build process by implementing a prebuilt version of the librocksdb library, which aligns with the main PR's updates to Docker image workflows.
  • build: use cargo binstall to speed up builds #2321: The integration of cargo binstall in this PR to speed up builds is relevant as it relates to improving the Docker build process, similar to the enhancements made in the main PR.
  • build: adjust docker build context #2336: This PR's adjustments to the Docker build context and optimizations in the Dockerfile are directly related to the changes made in the main PR regarding Docker image workflows.

Suggested reviewers

  • QuantumExplorer
  • lklimek

🐇 In the meadow where the bunnies play,
New Docker images come out to sway.
With runners fresh and manifests neat,
Our builds are faster, oh what a treat!
Hopping high with joy, we cheer,
For every change brings us near! 🌼


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between e508fdc and 40564d1.

📒 Files selected for processing (1)
  • .github/workflows/release-docker-image.yml (3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/release-docker-image.yml

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.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

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.

@shumkov shumkov self-assigned this Nov 22, 2024
@shumkov shumkov added this to the v1.6.0 milestone Nov 22, 2024
Copy link
Contributor

@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: 1

🧹 Outside diff range and nitpick comments (1)
.github/workflows/release-docker-image.yml (1)

Line range hint 137-144: Enhance manifest creation step robustness and security

While the implementation is functional, consider these improvements:

  1. Add error handling for manifest creation
  2. Verify digest signatures
  3. Clean up temporary files

Suggested enhancement:

  - name: Create manifest list and push
    working-directory: ${{ env.DIGEST_DIR_PATH }}
    run: |
+     set -euo pipefail
      ls -lah
+     # Verify all digests are present
+     expected_count=2  # amd64 and arm64
+     actual_count=$(ls | wc -l)
+     if [ "$actual_count" -ne "$expected_count" ]; then
+       echo "Error: Expected $expected_count digests, found $actual_count"
+       exit 1
+     fi
      docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
        $(printf '${{ inputs.image_org }}/${{ inputs.image_name }}@sha256:%s ' *)
+     # Verify manifest creation
+     if ! docker buildx imagetools inspect ${{ inputs.image_org }}/${{ inputs.image_name }}:${{ steps.docker_meta.outputs.version }} > /dev/null; then
+       echo "Error: Failed to verify manifest"
+       exit 1
+     fi
+     # Cleanup
+     rm -rf ${{ env.DIGEST_DIR_PATH }}/*
🧰 Tools
🪛 actionlint (1.7.3)

140-140: shellcheck reported issue in this script: SC2046:warning:2:33: Quote this to prevent word splitting

(shellcheck)


140-140: shellcheck reported issue in this script: SC2046:warning:3:3: Quote this to prevent word splitting

(shellcheck)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 92dd8f9 and 585eebf.

📒 Files selected for processing (1)
  • .github/workflows/release-docker-image.yml (2 hunks)
🔇 Additional comments (1)
.github/workflows/release-docker-image.yml (1)

Line range hint 1-144: Verify secrets access for GitHub-hosted runners

Since we're switching from self-hosted to GitHub-hosted runners, please verify that all required secrets are properly configured with appropriate permissions.

✅ Verification successful

Required secrets are properly referenced for GitHub-hosted runners

The workflow correctly references all necessary secrets for both AWS and Docker Hub authentication:

  • AWS credentials: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION
  • Docker Hub credentials: DOCKERHUB_USERNAME, DOCKERHUB_TOKEN

These secrets are used with appropriate actions:

  • AWS credentials with aws-actions/configure-aws-credentials@v4
  • Docker Hub credentials with docker/login-action@v3

The transition to GitHub-hosted runners doesn't affect the secrets usage as they are properly scoped and referenced.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if all required secrets are referenced in the workflow

echo "Required secrets:"
rg -o '\$\{\{\s*secrets\.[A-Za-z_]+\s*\}\}' | sort -u | sed 's/.*secrets\.\([A-Za-z_]*\).*/\1/'

echo -e "\nVerify these secrets are configured in repository settings:"
gh api repos/{owner}/{repo}/actions/secrets --jq '.secrets[].name'

Length of output: 560


Script:

#!/bin/bash
# Let's extract the required secrets directly from the workflow file
echo "Required secrets in the workflow:"
rg -o '\$\{\{\s*secrets\.[A-Za-z_]+\s*\}\}' .github/workflows/release-docker-image.yml | sort -u | sed 's/.*secrets\.\([A-Za-z_]*\).*/\1/'

Length of output: 303

.github/workflows/release-docker-image.yml Outdated Show resolved Hide resolved
Copy link
Contributor

@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: 3

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between dcf1b97 and 655e5fb.

📒 Files selected for processing (1)
  • Dockerfile (3 hunks)

Dockerfile Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
Copy link
Contributor

@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: 2

🧹 Outside diff range and nitpick comments (1)
Dockerfile (1)

Line range hint 1-700: Consider optimizing the build process further

The Dockerfile implementation is solid, but consider these optimizations:

  1. Use BuildKit's --mount=type=cache for npm/yarn cache in JavaScript builds
  2. Implement multi-platform builds using buildx for better ARM64 support
  3. Consider using cache-from and cache-to for distributed caching

These changes would improve build performance and cross-platform support.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 751fda0 and f6c3b90.

📒 Files selected for processing (1)
  • Dockerfile (3 hunks)
🧰 Additional context used
🪛 Hadolint (2.12.0)
Dockerfile

[error] 427-427: COPY with more than 2 arguments requires the last argument to end with /

(DL3021)

🔇 Additional comments (1)
Dockerfile (1)

Line range hint 335-426: LGTM! Well-structured build stage with proper caching

The build stage implementation is solid with:

  • Proper cargo registry and git caching
  • Correct environment variable handling
  • Appropriate build profile and feature flag management

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Show resolved Hide resolved
Copy link
Contributor

@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: 1

🧹 Outside diff range and nitpick comments (1)
Dockerfile (1)

Line range hint 1-700: Consider architectural improvements for better build performance

The Dockerfile follows good practices but could benefit from the following improvements:

  1. Consider using BuildKit's --mount=type=cache for npm/yarn cache in the JavaScript build stages
  2. The TODO comment about removing unnecessary workspace packages should be addressed to reduce build time and image size
  3. Consider implementing health checks for the services

Example implementation for health checks:

# Add to drive-abci stage
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
    CMD nc -z localhost 26658 || exit 1

# Add to dapi stage
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
    CMD nc -z localhost 2510 || exit 1
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between f6c3b90 and 9ab1452.

📒 Files selected for processing (1)
  • Dockerfile (2 hunks)
🔇 Additional comments (1)
Dockerfile (1)

321-321: ⚠️ Potential issue

Fix undefined $RELEASE variable in cargo chef prepare command

The $RELEASE variable is used but not defined, which could lead to build failures.

Apply this diff to fix the issue:

-RUN source $HOME/.cargo/env && \
-    source /root/env && \
-    cargo chef prepare $RELEASE --recipe-path recipe.json
+RUN source $HOME/.cargo/env && \
+    source /root/env && \
+    if [[ "${CARGO_BUILD_PROFILE}" == "release" ]] ; then \
+        cargo chef prepare --release --recipe-path recipe.json; \
+    else \
+        cargo chef prepare --recipe-path recipe.json; \
+    fi

Likely invalid or redundant comment.

Dockerfile Show resolved Hide resolved
Copy link
Contributor

@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: 1

🧹 Outside diff range and nitpick comments (2)
.github/workflows/release-docker-image.yml (2)

Line range hint 141-147: Add error handling for manifest creation

While the manifest list creation is well-implemented, consider adding error handling to ensure the process fails gracefully if any issues occur.

  - name: Create manifest list and push
    working-directory: ${{ env.DIGEST_DIR_PATH }}
    run: |
      ls -lah
+     if [ -z "$(ls -A)" ]; then
+       echo "Error: No digests found in directory"
+       exit 1
+     fi
      docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
        $(printf '${{ inputs.image_org }}/${{ inputs.image_name }}@sha256:%s ' *) || {
+       echo "Error: Failed to create manifest list"
+       exit 1
+     }
🧰 Tools
🪛 actionlint (1.7.3)

144-144: shellcheck reported issue in this script: SC2046:warning:2:33: Quote this to prevent word splitting

(shellcheck)


144-144: shellcheck reported issue in this script: SC2046:warning:3:3: Quote this to prevent word splitting

(shellcheck)


Line range hint 141-147: Consider adding manifest cleanup

To prevent accumulation of unused manifests over time, consider adding a cleanup step for old manifests after successful creation of new ones.

Example cleanup approach:

  1. List existing manifests older than X days
  2. Remove unused manifests
  3. Document the cleanup policy

Would you like me to provide a detailed implementation for this cleanup process?

🧰 Tools
🪛 actionlint (1.7.3)

144-144: shellcheck reported issue in this script: SC2046:warning:2:33: Quote this to prevent word splitting

(shellcheck)


144-144: shellcheck reported issue in this script: SC2046:warning:3:3: Quote this to prevent word splitting

(shellcheck)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 5298a3b and e508fdc.

📒 Files selected for processing (1)
  • .github/workflows/release-docker-image.yml (3 hunks)
🔇 Additional comments (2)
.github/workflows/release-docker-image.yml (2)

40-43: LGTM! Good choice of runners

Using the same Ubuntu runner for both architectures ensures build environment consistency. The setup correctly defines the matrix for multi-architecture builds.


36-36: Consider investigating the need for such a long timeout

A 120-minute timeout is quite long for a build job. While cross-platform builds can be time-consuming, it would be worth investigating if there are any optimization opportunities in the build process.

Consider:

  • Implementing build caching
  • Optimizing the Dockerfile layers
  • Running builds in parallel where possible
✅ Verification successful

120-minute timeout is justified for multi-architecture builds

The timeout value is appropriate given the workflow configuration:

  • Builds for multiple architectures (linux/amd64 and linux/arm64)
  • Uses QEMU for ARM64 emulation
  • Includes artifact upload/download and manifest creation steps
  • Performs complex Docker operations including cross-platform builds
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check recent workflow runs to analyze build times
gh run list --workflow=release-docker-image.yml --limit 5 --json durationInMinutes,conclusion \
  | jq '.[] | {duration: .durationInMinutes, status: .conclusion}'

Length of output: 403


Script:

#!/bin/bash
# Check recent workflow runs with correct fields
gh run list --workflow=release-docker-image.yml --limit 5 --json startedAt,conclusion,updatedAt \
  | jq '.[] | {
      duration: (
        if (.startedAt != null and .updatedAt != null) then
          ((sub("(?<date>[0-9]{4}-[0-9]{2}-[0-9]{2})T(?<time>[0-9]{2}:[0-9]{2}:[0-9]{2}).*"; "\(.date) \(.time)") | fromdate) - 
           (sub("(?<date>[0-9]{4}-[0-9]{2}-[0-9]{2})T(?<time>[0-9]{2}:[0-9]{2}:[0-9]{2}).*"; "\(.date) \(.time)") | fromdate)) / 60
        else
          null
        end
      ),
      status: .conclusion
    }'

# Also check if there are any multi-platform build configurations
rg -l 'platform.*linux/(amd64|arm64)' --type yaml

Length of output: 584


Script:

#!/bin/bash
# Let's check the workflow file directly for platform configurations and build steps
cat .github/workflows/release-docker-image.yml

# Also check for any Docker build commands or platform specifications
rg "docker buildx" -A 5 -B 2 --type yaml

Length of output: 5354

.github/workflows/release-docker-image.yml Show resolved Hide resolved
Copy link
Contributor

@lklimek lklimek left a comment

Choose a reason for hiding this comment

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

Looks good, but please check Rabbit comments

@shumkov shumkov merged commit dd54205 into v1.6-dev Nov 25, 2024
18 checks passed
@shumkov shumkov deleted the ci/release branch November 25, 2024 08:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants