ci: test on stable rust, not nightly #115
Conversation
WalkthroughThe pull request modifies the GitHub Actions workflow configurations in Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (1).github/workflows/github-pages.yml (1)Line range hint The workflow maintains all essential components for proper documentation generation and deployment. The removal of commented lines helps improve readability without affecting functionality. Let's verify that the documentation generation step works with stable Rust: ✅ Verification successfulThe previous attempt didn't yield results, so let's examine the broader context by:
This will help us verify if the documentation generation is compatible with stable Rust. The GitHub Pages workflow is compatible with stable Rust Based on the analysis of the codebase:
The workflow will work correctly with stable Rust as all the documentation generation tools and flags used are supported in the stable toolchain. 🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Verify the documentation generation commands are compatible with stable Rust
# Check if there are any nightly-specific features or attributes in the documentation
rg -l '#!\[feature\('
# Check for any doc comments that might reference nightly-only features
rg -l '//!.*nightly|///.*nightly'
# Look for any conditional compilation that might depend on nightly
ast-grep --pattern 'cfg(nightly)'
Length of output: 95 Script: #!/bin/bash
# Let's check for any Rust-specific configuration or toolchain files
fd -e toml -x cat {}
# Check if there are any other workflow files that might specify Rust toolchain
fd -g '*.yml' -g '*.yaml' .github/workflows -x cat {}
# Look for any documentation-specific configuration
fd -g 'rustdoc*' -g 'doc*' -x cat {}
Length of output: 15897 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 (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
.github/workflows/test.yml (1)
Line range hint
34-48: Well-structured CI configuration with good practices.The CI setup demonstrates good practices:
- Uses stable toolchain for reliability
- Maintains proper test timeouts via environment variables
- Preserves coverage reporting with grcov
- Includes proper error handling with docker logs archival
Consider adding a comment in the workflow file explaining why stable toolchain is preferred to help future maintainers.
- uses: ./.github/actions/deps with: + # Using stable toolchain for reliable CI builds toolchain: stable🧰 Tools
🪛 actionlint (1.7.4)
31-31: the runner of "actions/checkout@v3" 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
📒 Files selected for processing (1)
.github/workflows/test.yml(2 hunks)
🔇 Additional comments (2)
.github/workflows/test.yml (2)
39-39: LGTM! Test command simplification maintains functionality.
Removing the nightly-specific -Zunstable-options --ensure-time flags is appropriate since test timeouts are already properly managed through the RUST_TEST_TIME_* environment variables defined at the job level.
Let's verify the test timeout configuration:
Also applies to: 48-48
✅ Verification successful
Test timeout configuration is properly maintained
The verification confirms that:
- Test timeouts are correctly configured through environment variables (
RUST_TEST_TIME_*) at the job level - Individual test steps have their own
timeout-minutessettings - No conflicting timeout configurations exist in Cargo.toml files
- The removal of
-Zunstable-options --ensure-timeflags doesn't impact the timeout functionality
The test timeout behavior is maintained through a robust combination of workflow-level timeouts (15 minutes), step-level timeouts (6 minutes), and granular test timeouts via environment variables (5s warning, 10s kill).
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify test timeout configuration consistency
# Check if there are any other test timeout configurations that might conflict
# Look for any other test timeout configurations
rg -g '!.git' 'test.*time|timeout'
# Check for any cargo config files that might override test settings
fd -g 'config.toml' -g '.cargo/config*'
Length of output: 708
Script:
#!/bin/bash
# Let's check the workflow file to understand the test timeout configuration
cat .github/workflows/test.yml
# Also check for any test-related configuration in Cargo.toml files
fd Cargo.toml --exec grep -l "test" {} \; --exec cat {}
Length of output: 4681
34-34: LGTM! Switching to stable toolchain is a good practice.
Using the stable toolchain instead of nightly is generally preferred for CI as it provides more consistent and reliable builds.
Let's verify there are no nightly-only features being used:
✅ Verification successful
Switching to stable toolchain is safe and recommended
The verification confirms that the codebase doesn't use any nightly-only Rust features. The only feature-related findings are:
- Standard conditional feature flags (
#![cfg_attr(...)]and#![cfg(feature = "grpc")]) - A minimum rust-version of 1.80 specified in Cargo.toml
- No usage of unstable features in the Rust code
The .rustfmt.toml contains unstable_features = true, but this only affects code formatting and doesn't impact the build process.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential nightly-only feature usage
# Look for #![feature(...)] attributes which typically indicate nightly features
# Search for feature attributes in rust files
rg '#!\[feature'
# Search for specific nightly feature gates in Cargo.toml files
rg '^\s*features\s*=' -t toml
Length of output: 50
Script:
#!/bin/bash
# Let's try a more comprehensive search for nightly features
# Look for any Rust files first to confirm we have access to them
fd -e rs
# Search for unstable features in a case-insensitive manner
rg -i 'unstable|nightly' -g '*.rs' -g '*.toml'
# Look for feature gates with more flexible pattern
rg '#!\[.*feature' -g '*.rs'
# Check Cargo.toml for rust-version specification
fd -g 'Cargo.toml' --exec cat {}
Length of output: 7301
Issue being fixed or feature implemented
Github Actions run tests on rust nightly, which fails.
See https://github.com/dashpay/rs-tenderdash-abci/actions/runs/12050788549
What was done?
Switched to stable
How Has This Been Tested?
Pass GH Actions
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit