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: changes to contract builds #605

Merged
merged 17 commits into from
Nov 20, 2024
Merged

ci: changes to contract builds #605

merged 17 commits into from
Nov 20, 2024

Conversation

crnbarr93
Copy link
Contributor

@crnbarr93 crnbarr93 commented Nov 5, 2024

Motivation

These changes update the rust.yml CI workflow to only build contracts on pull requests and only release artifacts on pull requests to development or main. Build can be triggered manually via the GitHub actions UI.

Implementation

Conditional steps were added to the appropriate actions in rust.yml

Summary by CodeRabbit

Summary by CodeRabbit

  • Bug Fixes

    • Removed the obsolete ibc-tests job from the workflow.
  • Chores

    • Streamlined the workflow for pull requests by adding conditional checks for job execution, enhancing efficiency.
    • Replaced Docker commands with make commands for building contracts and generating schemas, optimizing the release process.
    • Added instructions for building contracts from source for the arm-64 architecture.
    • Introduced a new label, "ci: skip-build", to the Dependabot configuration for updates.
    • Simplified the deploy target dependencies in the Makefile.
    • Added quiet mode to unit and integration test commands to reduce output verbosity.
    • Introduced a new GitHub Actions workflow for building contracts and schemas, ensuring automated artifact generation.
    • Updated the Rust toolchain configuration in deployment workflows for improved management.

These changes enhance the overall reliability and performance of the build and release processes.

@crnbarr93 crnbarr93 added the ci: skip-changelog Skips the changelog check in CI label Nov 5, 2024
@crnbarr93 crnbarr93 requested a review from SlayerAnsh November 5, 2024 10:16
Copy link
Contributor

coderabbitai bot commented Nov 5, 2024

Caution

Review failed

The pull request is closed.

Walkthrough

The pull request introduces modifications to several GitHub Actions workflow files, a Rust source file, and a Makefile. The .github/workflows/release.yml file has been updated to replace Docker commands with make commands for building contracts and generating schemas. The .github/workflows/rust.yml file has undergone changes to optimize linting and testing jobs, including the removal of certain jobs and the introduction of a matrix strategy for tests. In the Rust source file packages/std/src/ado_contract/app.rs, a conditional compilation block for module validation has been removed. Additionally, the .github/dependabot.yml file has been updated to include a new label, and the Makefile has been adjusted to streamline test commands.

Changes

File Path Change Summary
.github/workflows/release.yml Replaced Docker commands with make commands for building contracts and generating schemas. Added a new step "Create version map". Updated release instructions for arm-64 architecture.
.github/workflows/rust.yml Updated linting to run concurrently; added matrix strategy for contract-tests. Removed build, ibc-tests, and build-schemas jobs. Updated artifact upload action version.
packages/std/src/ado_contract/app.rs Removed conditional compilation block for module validation in execute_update_app_contract method.
.github/dependabot.yml Added "ci: skip-build" label for updates in cargo and github-actions package ecosystems.
Makefile Updated deploy target's dependencies from build make-version-map to build version-map. Added --quiet flag to unit-test and integration-test targets.
.github/workflows/build.yml Introduced a new workflow for building contracts and schemas with jobs build and build-schemas.
.github/workflows/deploy.yml Updated Rust toolchain usage and removed certain parameters from the deployment job.

Possibly related PRs

  • ci: release workflow #601: The changes in the release workflow (release.yml) are directly related to the main PR, as both involve modifications to GitHub Actions workflows for managing releases and optimizing contracts.
  • build: added makefile #606: This PR introduces a Makefile that centralizes build scripts, which aligns with the changes in the main PR that replace Docker commands with make commands in the workflow.
  • ci: git actions versions #624: The update to the GitHub Actions versions in this PR is relevant as it pertains to the CI workflow, similar to the changes made in the main PR regarding the release workflow.
  • ci: add dependabot.yml #625: The introduction of Dependabot configuration in this PR is related to the overall maintenance and automation improvements reflected in the main PR's workflow changes.

Suggested labels

backport/v1.1.x

Suggested reviewers

  • cowboy0015
  • joemonem
  • SlayerAnsh

Poem

🐰 In the meadow, changes bloom,
With workflows bright, they chase the gloom.
Sudo hops in, a new command,
While pull requests take a stand.
Goodbye to tests that once were here,
A simpler path, let’s give a cheer! 🌼


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.

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/rust.yml (2)

79-82: Fix trailing spaces in YAML conditions

The upload conditions are logically correct and align with the PR objectives. However, there are trailing spaces that should be removed for better YAML formatting.

-        if: >
-          github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
-          contains(github.event.pull_request.labels.*.name, 'ci: build')
+        if: >
+          github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
+          contains(github.event.pull_request.labels.*.name, 'ci: build')
🧰 Tools
🪛 yamllint

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)


101-104: Fix trailing spaces in schema upload conditions

The conditions mirror the build job's upload conditions correctly, but contain the same trailing spaces issue.

-        if: >
-          github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
-          contains(github.event.pull_request.labels.*.name, 'ci: build')
+        if: >
+          github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
+          contains(github.event.pull_request.labels.*.name, 'ci: build')
🧰 Tools
🪛 yamllint

[error] 102-102: trailing spaces

(trailing-spaces)


[error] 103-103: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between e1a79c0 and 16e9b69.

📒 Files selected for processing (3)
  • .github/workflows/release.yml (1 hunks)
  • .github/workflows/rust.yml (2 hunks)
  • packages/std/src/ado_contract/app.rs (0 hunks)
💤 Files with no reviewable changes (1)
  • packages/std/src/ado_contract/app.rs
🧰 Additional context used
🪛 actionlint
.github/workflows/rust.yml

95-95: the runner of "actions/checkout@v2" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🪛 yamllint
.github/workflows/rust.yml

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)


[error] 102-102: trailing spaces

(trailing-spaces)


[error] 103-103: trailing spaces

(trailing-spaces)

🔇 Additional comments (3)
.github/workflows/release.yml (1)

19-19: Consider investigating the need for sudo.

While adding sudo might resolve permission issues during schema generation, it's generally recommended to avoid using elevated permissions in CI/CD workflows unless absolutely necessary.

Consider investigating:

  1. Why elevated permissions are needed for schema generation
  2. If the permission issues can be resolved in the build_schema.sh script itself
  3. If file/directory permissions can be properly set during earlier steps

Let's examine the script to understand the permission requirements:

.github/workflows/rust.yml (2)

58-58: LGTM: Build job condition aligns with PR objectives

The condition to only run builds on pull requests is correctly implemented and aligns with the PR's goal of refining the build process.


93-93: LGTM: Schema build condition is consistent

The condition matches the build job's PR-only execution policy, maintaining consistency across the workflow.

.github/workflows/rust.yml Outdated Show resolved Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
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/rust.yml (1)

79-82: Fix trailing spaces in multiline conditions

The multiline conditions have trailing spaces that should be removed for cleaner YAML.

Apply this formatting fix to both conditions:

        if: >
-          github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
+          github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
           contains(github.event.pull_request.labels.*.name, 'ci: build')

Also applies to: 101-104

🧰 Tools
🪛 yamllint

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 16e9b69 and b3c9922.

📒 Files selected for processing (1)
  • .github/workflows/rust.yml (2 hunks)
🧰 Additional context used
🪛 yamllint
.github/workflows/rust.yml

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)


[error] 102-102: trailing spaces

(trailing-spaces)


[error] 103-103: trailing spaces

(trailing-spaces)

🔇 Additional comments (2)
.github/workflows/rust.yml (2)

58-58: LGTM! Optimization to run builds only on PRs

The added conditions align well with the PR objectives, ensuring that contract builds and schema generations only occur during pull requests. This is a good optimization that prevents unnecessary builds on direct pushes.

Also applies to: 93-93


79-82: LGTM! Smart conditional artifact uploads

The added conditions ensure artifacts are only uploaded for PRs targeting important branches or those explicitly marked for building. This aligns perfectly with the PR objectives and provides good control over artifact generation.

Also applies to: 101-104

🧰 Tools
🪛 yamllint

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)

.github/workflows/rust.yml Outdated Show resolved Hide resolved
@crnbarr93 crnbarr93 changed the title ci: changes to contract builds [WIP] ci: changes to contract builds Nov 7, 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/rust.yml (1)

79-83: Fix trailing spaces in conditions

The conditional logic is correct but there are trailing spaces that should be removed.

Apply this diff to fix the trailing spaces:

        if: >
-          github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
+          github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
           contains(github.event.pull_request.labels.*.name, 'ci: build')

Also applies to: 101-104

🧰 Tools
🪛 yamllint

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between b3c9922 and a1aac8e.

📒 Files selected for processing (2)
  • .github/workflows/release.yml (1 hunks)
  • .github/workflows/rust.yml (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/release.yml
🧰 Additional context used
🪛 yamllint
.github/workflows/rust.yml

[error] 80-80: trailing spaces

(trailing-spaces)


[error] 81-81: trailing spaces

(trailing-spaces)


[error] 102-102: trailing spaces

(trailing-spaces)


[error] 103-103: trailing spaces

(trailing-spaces)

🔇 Additional comments (2)
.github/workflows/rust.yml (2)

58-58: LGTM: PR-only job conditions align with objectives

The added conditions if: github.event_name == 'pull_request' correctly implement the requirement to build contracts only on pull requests.

Also applies to: 93-93


Line range hint 1-1: Verify removal of ibc-tests job

The workflow no longer includes the ibc-tests job. Please confirm if this removal was intentional and that IBC functionality is being tested elsewhere.

🧰 Tools
🪛 actionlint

60-60: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

.github/workflows/rust.yml Outdated Show resolved Hide resolved
@crnbarr93 crnbarr93 added the ci: skip-build Skip artifact uploads label Nov 19, 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 (2)
.github/workflows/rust.yml (2)

58-63: Fix trailing spaces in conditional statement

Remove trailing spaces from the conditional for better maintainability.

    if: >
      github.event_name == 'pull_request' && (
-        (github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
+        (github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
          contains(github.event.pull_request.labels.*.name, 'ci: build')) && !contains(github.event.pull_request.labels.*.name, 'ci: skip-build')
      )
🧰 Tools
🪛 yamllint

[error] 60-60: trailing spaces

(trailing-spaces)


[error] 61-61: trailing spaces

(trailing-spaces)


95-100: Fix trailing spaces in conditional statement

Remove trailing spaces from the conditional for better maintainability.

    if: >
      github.event_name == 'pull_request' && (
-        (github.base_ref == 'development' || 
-          github.base_ref == 'main' || 
+        (github.base_ref == 'development' ||
+          github.base_ref == 'main' ||
          contains(github.event.pull_request.labels.*.name, 'ci: build')) && !contains(github.event.pull_request.labels.*.name, 'ci: skip-build')
      )
🧰 Tools
🪛 yamllint

[error] 97-97: trailing spaces

(trailing-spaces)


[error] 98-98: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between a1aac8e and bf3e436.

📒 Files selected for processing (2)
  • .github/workflows/release.yml (2 hunks)
  • .github/workflows/rust.yml (3 hunks)
🧰 Additional context used
🪛 yamllint
.github/workflows/rust.yml

[error] 60-60: trailing spaces

(trailing-spaces)


[error] 61-61: trailing spaces

(trailing-spaces)


[error] 97-97: trailing spaces

(trailing-spaces)


[error] 98-98: trailing spaces

(trailing-spaces)

🔇 Additional comments (5)
.github/workflows/release.yml (4)

43-59: Documentation updates look great!

The release documentation has been comprehensively updated with:

  • Consistent use of Make commands
  • Clear instructions for both standard and arm-64 builds
  • Updated schema generation steps

15-16: Verify Makefile build target configuration

The switch to make build simplifies the build process, but we should ensure the Makefile is properly configured.

✅ Verification successful

Build configuration is properly set up

The make build command is correctly configured:

  • Makefile contains the build target that executes scripts/build_all.sh
  • build_all.sh properly uses the CosmWasm optimizer Docker image to build the contracts
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify Makefile exists and contains the build target
# Expected: Makefile with 'build' target defined

# Check if Makefile exists and contains build target
if [ -f "Makefile" ]; then
    echo "Makefile found. Checking for build target..."
    grep -A 5 "^build:" Makefile
else
    echo "Error: Makefile not found"
    exit 1
fi

Length of output: 460


Script:

#!/bin/bash
# Let's verify the build_all.sh script exists and check its content
if [ -f "scripts/build_all.sh" ]; then
    echo "build_all.sh found. Content:"
    cat scripts/build_all.sh
else
    echo "Error: scripts/build_all.sh not found"
fi

Length of output: 362


22-22: Verify schema generation consistency

The change from ./build_schema.sh to make schemas should maintain the same schema generation output.

✅ Verification successful

Schema generation remains consistent with the previous implementation

The change from ./build_schema.sh to make schemas is a simple wrapper that maintains the exact same schema generation process. The Makefile target directly calls the same ./scripts/build_schema.sh script, ensuring identical output. The script properly handles schema generation for all contracts by:

  1. Creating a schemas directory if it doesn't exist
  2. Running cargo schema for each contract
  3. Organizing schemas by contract version
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify schema generation configuration
# Expected: Makefile schemas target that generates equivalent output

# Check for old schema script (for reference)
if [ -f "build_schema.sh" ]; then
    echo "Old schema script still exists and should be removed"
fi

# Check Makefile for schemas target
if [ -f "Makefile" ]; then
    echo "Checking schemas target implementation..."
    grep -A 10 "^schemas:" Makefile
fi

Length of output: 517


Script:

#!/bin/bash
# Check if the script exists and examine its content
if [ -f "./scripts/build_schema.sh" ]; then
    echo "=== Content of build_schema.sh ==="
    cat "./scripts/build_schema.sh"
else
    echo "build_schema.sh not found in scripts directory"
fi

# Search for any other schema-related files
echo -e "\n=== Looking for schema-related files ==="
fd schema

Length of output: 3520


17-18: Document the purpose of version-map target

A new step for creating a version map has been added, but its purpose and output are not documented.

✅ Verification successful

Let me gather more information about the version map target since the previous script had some issues.


Let me check the content of the version map script to understand its implementation.


Based on the gathered information, I can now provide a final response:

Version map creation step is well-documented in the codebase

The version-map target is properly documented and implemented:

  • Creates a JSON mapping between contracts and their versions in artifacts/version_map.json
  • Used as part of the deployment process (required by deploy target)
  • Implementation in scripts/build_version_map.sh is clear and well-commented

The review comment's concern about documentation has been addressed as the purpose is clearly documented in the Makefile comment: "Generates a mapping between each contract and its version"

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for version-map target and any related documentation
# Expected: Makefile target and documentation explaining its purpose

# Check Makefile for version-map target
if [ -f "Makefile" ]; then
    echo "Checking for version-map target..."
    grep -A 5 "^version-map:" Makefile
fi

# Look for related documentation
fd -t f -e md -e txt . | xargs rg -l "version[- ]map"

Length of output: 460


Script:

#!/bin/bash
# Check Makefile content for version-map target and surrounding context
if [ -f "Makefile" ]; then
    echo "=== Checking Makefile for version-map target ==="
    grep -B 2 -A 5 "version[- ]map" Makefile
fi

# Look for any scripts that might be related to version map
echo -e "\n=== Checking for related scripts ==="
fd -t f "version[_-]map" scripts/

# Search for version map references in documentation
echo -e "\n=== Checking documentation for version map mentions ==="
fd -t f -e md . | xargs rg -l "version[- ]map"

Length of output: 1757


Script:

#!/bin/bash
# Check the content of the version map script
echo "=== Content of build_version_map.sh ==="
cat scripts/build_version_map.sh

# Look for any usage of this version map in the codebase
echo -e "\n=== Usage of version map in codebase ==="
rg -l "version[_-]map" --type rust

Length of output: 1370

.github/workflows/rust.yml (1)

106-106: Verify schemas make target exists in repository

The schema build step now uses a make command. Let's verify this target is properly defined.

✅ Verification successful

Let me search for any Makefile in the repository to ensure we haven't missed it in a different location.


Let me check the content of the Makefile to see the actual definition of the schemas target.


Let me verify if the script referenced in the schemas target exists.


The schemas make target is properly defined and executable

The schemas target exists in the Makefile and executes the ./scripts/build_schema.sh script, which is present and has the correct executable permissions. The target is properly defined with appropriate build steps and success message output.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify schemas make target exists and is properly defined

# Check if Makefile exists and contains required target
if [ -f "Makefile" ]; then
  echo "Checking schemas make target..."
  
  # Check for 'schemas' target
  if ! grep -q "^schemas:" Makefile; then
    echo "ERROR: 'schemas' target not found in Makefile"
  fi
  
  # Display target definition if found
  echo "Target definition:"
  sed -n '/^schemas:/,/^[^\t]/{/^[^\t]/q;p}' Makefile
else
  echo "ERROR: Makefile not found in repository root"
fi

Length of output: 226


Script:

#!/bin/bash
# Find all Makefiles in the repository
fd Makefile

# Also search for any file that might define the schemas target
rg -l "schemas:"

Length of output: 48


Script:

#!/bin/bash
# Display the content of Makefile
cat Makefile

Length of output: 2599


Script:

#!/bin/bash
# Check if the build_schema.sh script exists and is executable
if [ -f "./scripts/build_schema.sh" ]; then
    echo "build_schema.sh exists"
    ls -l ./scripts/build_schema.sh
else
    echo "build_schema.sh not found"
fi

Length of output: 201

.github/workflows/rust.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: 0

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

58-63: Consider extracting duplicated conditions into a reusable expression.

The same conditional logic is duplicated between the build and build-schemas jobs. This could lead to maintenance issues if the conditions need to be updated.

Consider using GitHub Actions' expression syntax to define a reusable condition. Here's how:

# At the top of the workflow file
name: Formatting Check & Test

on:
  push:
    paths: ["**.*"]
  pull_request:
    branches: [main, development]

env:
  CARGO_TERM_COLOR: always
+ BUILD_CONDITION: >
+   !contains(github.event.pull_request.labels.*.name, 'ci: skip-build') &&
+   github.event_name == 'pull_request' &&
+   (github.base_ref == 'development' ||
+    github.base_ref == 'main' ||
+    contains(github.event.pull_request.labels.*.name, 'ci: build'))

jobs:
  # ... other jobs ...

  build:
    if: ${{ env.BUILD_CONDITION }}
    # ... rest of the job config ...

  build-schemas:
    if: ${{ env.BUILD_CONDITION }}
    # ... rest of the job config ...

Also, remove the trailing spaces in the conditions to fix the linting errors.

Also applies to: 95-100

🧰 Tools
🪛 yamllint

[error] 60-60: trailing spaces

(trailing-spaces)


[error] 61-61: trailing spaces

(trailing-spaces)


[error] 62-62: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between bf3e436 and fac549f.

📒 Files selected for processing (2)
  • .github/dependabot.yml (2 hunks)
  • .github/workflows/rust.yml (3 hunks)
✅ Files skipped from review due to trivial changes (1)
  • .github/dependabot.yml
🧰 Additional context used
🪛 yamllint
.github/workflows/rust.yml

[error] 60-60: trailing spaces

(trailing-spaces)


[error] 61-61: trailing spaces

(trailing-spaces)


[error] 62-62: trailing spaces

(trailing-spaces)


[error] 97-97: trailing spaces

(trailing-spaces)


[error] 98-98: trailing spaces

(trailing-spaces)


[error] 99-99: trailing spaces

(trailing-spaces)

🔇 Additional comments (1)
.github/workflows/rust.yml (1)

77-79: Review the necessity of using sudo for make version-map.

Using sudo in CI/CD workflows can be a security risk. If elevated permissions are needed, consider:

  1. Adjusting file permissions in the Dockerfile or earlier in the workflow
  2. Modifying the script to not require root privileges
  3. Using GitHub Actions' GITHUB_TOKEN for any necessary permissions

Let's check why sudo might be needed:

@crnbarr93 crnbarr93 changed the title [WIP] ci: changes to contract builds ci: changes to contract builds Nov 19, 2024
@crnbarr93 crnbarr93 requested a review from joemonem November 19, 2024 14:52
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: 0

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

54-56: Remove trailing spaces in YAML conditions

Remove trailing spaces from the following lines to improve YAML formatting:

  • Line 54: development' ||
  • Line 55: main ||
  • Line 56: 'ci: build'))
  • Line 91: development' ||
  • Line 92: main ||
  • Line 93: 'ci: build'))

Also applies to: 91-93

🧰 Tools
🪛 yamllint

[error] 54-54: trailing spaces

(trailing-spaces)


[error] 55-55: trailing spaces

(trailing-spaces)


[error] 56-56: trailing spaces

(trailing-spaces)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 96cecb2 and aac7e88.

📒 Files selected for processing (2)
  • .github/workflows/rust.yml (4 hunks)
  • Makefile (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • Makefile
🧰 Additional context used
🪛 yamllint
.github/workflows/rust.yml

[error] 54-54: trailing spaces

(trailing-spaces)


[error] 55-55: trailing spaces

(trailing-spaces)


[error] 56-56: trailing spaces

(trailing-spaces)


[error] 91-91: trailing spaces

(trailing-spaces)


[error] 92-92: trailing spaces

(trailing-spaces)


[error] 93-93: trailing spaces

(trailing-spaces)

🔇 Additional comments (6)
.github/workflows/rust.yml (6)

37-37: LGTM! Good optimization using matrix strategy

The matrix strategy for test types allows parallel execution of integration and unit tests, improving CI efficiency.


46-46: LGTM! Good simplification using make targets

Using make commands with the matrix variable simplifies the workflow and improves maintainability.


52-57: LGTM! Well-structured conditional build triggers

The conditions effectively implement the PR objectives by:

  • Building only on pull requests
  • Checking for skip-build labels
  • Restricting to development/main branches or ci:build label
🧰 Tools
🪛 yamllint

[error] 54-54: trailing spaces

(trailing-spaces)


[error] 55-55: trailing spaces

(trailing-spaces)


[error] 56-56: trailing spaces

(trailing-spaces)


71-73: LGTM! Good use of make targets for build steps

The build steps correctly use the build and version-map make targets, which are properly defined in the Makefile.


89-94: Conditions mirror build job as expected

The conditions correctly match the build job, ensuring consistent behavior for schema generation.

🧰 Tools
🪛 yamllint

[error] 91-91: trailing spaces

(trailing-spaces)


[error] 92-92: trailing spaces

(trailing-spaces)


[error] 93-93: trailing spaces

(trailing-spaces)


100-100: LGTM! Consistent use of make target

The schema generation step correctly uses the make target, maintaining consistency with other build steps.

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

🧹 Outside diff range and nitpick comments (3)
.github/workflows/rust.yml (2)

26-31: Enhance error handling for parallel processes

While parallelizing the linting checks is a good optimization, consider adding error handling to ensure failures are properly caught and reported.

 - run: cargo fetch --quiet
 - name: Run linting checks
   run: |
+    set -eo pipefail
     cargo clippy --quiet --all --all-targets -- -D warnings &
     cargo fmt -- --check &
-    wait
+    if ! wait; then
+      echo "One or more linting checks failed"
+      exit 1
+    fi

40-40: Consider adding timeouts and caching

While the matrix strategy for test types is a good improvement, consider these enhancements:

  1. Add a timeout to prevent hanging test jobs
  2. Implement cargo caching to speed up builds

Add timeout to the job:

contract-tests:
  timeout-minutes: 30

Add caching:

steps:
  - uses: actions/cache@v4
    with:
      path: |
        ~/.cargo/registry
        ~/.cargo/git
        target
      key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

Also applies to: 49-49

.github/workflows/build.yml (1)

8-57: Consider workflow optimization opportunities

To improve CI efficiency, consider:

  1. Using GitHub Actions cache for Rust dependencies
  2. Implementing job dependencies and parallel execution where possible
  3. Reusing common setup steps through composite actions

Example cache implementation:

- uses: actions/cache@v3
  with:
    path: |
      ~/.cargo/registry
      ~/.cargo/git
      target
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
🧰 Tools
🪛 actionlint

15-15: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between aac7e88 and e3a0e09.

📒 Files selected for processing (2)
  • .github/workflows/build.yml (1 hunks)
  • .github/workflows/rust.yml (3 hunks)
🧰 Additional context used
🪛 actionlint
.github/workflows/build.yml

15-15: the runner of "actions-rs/toolchain@v1" action is too old to run on GitHub Actions. update the action's version to fix this issue

(action)

🔇 Additional comments (2)
.github/workflows/rust.yml (1)

Line range hint 1-49: Overall workflow improvements look good

The changes effectively streamline the CI process by:

  • Parallelizing linting checks
  • Using a matrix strategy for tests
  • Moving build jobs to a separate workflow
  • Simplifying test execution with make commands

These changes align well with the PR objectives of refining the build process and improving workflow efficiency.

.github/workflows/build.yml (1)

1-7: LGTM! Workflow triggers align with PR objectives.

The workflow configuration correctly implements the requirement to build only on pull requests targeting main/development branches, with an additional manual trigger option.

.github/workflows/build.yml Show resolved Hide resolved
.github/workflows/build.yml Show resolved Hide resolved
.github/workflows/build.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: 1

🧹 Outside diff range and nitpick comments (2)
.github/workflows/rust.yml (2)

20-23: Consider pinning the rust-toolchain action version

While using dtolnay/rust-toolchain is a good choice, using the @master tag could lead to unexpected breaks if the upstream action changes. Consider pinning to a specific version for better stability.

-      - uses: dtolnay/rust-toolchain@master
+      - uses: dtolnay/rust-toolchain@v1

46-46: Consider adding test result artifacts

To help with debugging failed tests, consider uploading test results as artifacts:

      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: test-results-${{ matrix.test-type }}
          path: target/debug/test-results
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between e3a0e09 and 6166721.

📒 Files selected for processing (3)
  • .github/workflows/build.yml (1 hunks)
  • .github/workflows/deploy.yml (1 hunks)
  • .github/workflows/rust.yml (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/build.yml
🔇 Additional comments (3)
.github/workflows/rust.yml (2)

24-29: Well-optimized linting setup!

The parallel execution of clippy and fmt checks with background processes is an excellent optimization. The quiet flags reduce log noise while maintaining functionality, and the wait command ensures both complete. The -D warnings flag maintains strict checking standards.


38-38: Excellent use of matrix strategy for test separation!

The matrix approach for different test types is a good practice that improves visibility of test failures and allows for potential parallel execution.

Also applies to: 46-46

.github/workflows/deploy.yml (1)

Line range hint 1-90: Overall workflow structure looks solid!

The workflow demonstrates good practices with:

  • Proper access control
  • Robust artifact handling
  • Comprehensive environment configuration
  • Appropriate error handling for deployments

.github/workflows/deploy.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: 0

🧹 Outside diff range and nitpick comments (2)
.github/workflows/rust.yml (2)

24-29: Consider error handling for parallel linting checks.

While parallelizing the checks is good for performance, it might make debugging harder if multiple checks fail simultaneously. Consider adding set -e and redirecting each check's output to separate log files for better error tracking.

 run: |
+  set -e
-  cargo clippy --quiet --all --all-targets -- -D warnings &
-  cargo fmt -- --check &
+  cargo clippy --quiet --all --all-targets -- -D warnings > clippy.log 2>&1 &
+  cargo fmt -- --check > fmt.log 2>&1 &
   wait
+  cat clippy.log fmt.log

Line range hint 1-46: Well-structured workflow optimization.

The removal of build-related jobs and focus on essential checks aligns well with the PR objectives. This separation of concerns improves workflow maintainability and efficiency. Consider documenting these architectural decisions in the repository's CI/CD documentation to help future contributors understand the workflow structure.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 6166721 and 42a08f6.

📒 Files selected for processing (3)
  • .github/workflows/build.yml (1 hunks)
  • .github/workflows/deploy.yml (1 hunks)
  • .github/workflows/rust.yml (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • .github/workflows/build.yml
  • .github/workflows/deploy.yml
🔇 Additional comments (3)
.github/workflows/rust.yml (3)

20-23: LGTM! Toolchain setup looks good.

The switch to dtolnay/rust-toolchain@v1 is a good choice. Just verify that Rust 1.75.0 is the intended version for your project's compatibility requirements.


38-38: LGTM! Good use of matrix strategy.

The matrix configuration for test types enables efficient parallel execution while keeping the workflow maintainable.


43-46: LGTM! Clean and efficient test execution setup.

The simplified make command and consistent toolchain configuration provide a clean approach to test execution.

@crnbarr93 crnbarr93 merged commit 5627873 into development Nov 20, 2024
5 of 6 checks passed
@crnbarr93 crnbarr93 deleted the connor/ci-changes branch November 20, 2024 13:10
@coderabbitai coderabbitai bot mentioned this pull request Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci: skip-build Skip artifact uploads ci: skip-changelog Skips the changelog check in CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants