Ci/publish #672
Ci/publish #672
Conversation
|
Note Reviews pausedUse the following commands to manage reviews:
WalkthroughThe changes in this pull request introduce several modifications across multiple files. A new section for Changes
Suggested reviewers
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 (
|
size-limit report 📦
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ |
ccamel
force-pushed
the
ci/publish
branch
2 times, most recently
from
f7de8b7 to
047c502
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (3)
contracts/axone-objectarium/Cargo.toml (1)
Line range hint
26-45: Consider using workspace inheritance for common dependency versionsSeveral dependencies have specific version requirements. Consider moving common dependencies to the workspace to ensure version consistency across crates.
Dependencies to consider moving to workspace:
- base16ct
- bs58
- derive_builder
- either
- enum-iterator
- lzma-rs
- md-5
- sha2
- snap
contracts/axone-dataverse/Cargo.toml (1)
Line range hint
29-47: Consider using workspace inheritance for common dependency versionsSeveral dependencies have specific version requirements. Consider moving common dependencies to the workspace for better maintainability.
Dependencies to consider moving to workspace:
- base64
- bech32
- bs58
- itertools
- multibase
- ripemd
- sha2
- unsigned-varint
Makefile.toml (1)
647-659: Consider adding explicit version bump strategyThe current implementation might benefit from a more explicit version bump strategy. Consider adding a separate task for version management using
cargo workspaces versionbefore publishing.+[tasks.bump-versions] +args = [ + "workspaces", + "version", + "--all", + "--exact", + "--no-git-commit" +] +command = "cargo" +description = "Bump versions of all workspace crates" + [tasks.publish-crates] args = [ "workspaces", "publish", "skip", ] command = "cargo" -dependencies = ["install-cargo-workspaces"] +dependencies = ["install-cargo-workspaces", "bump-versions"] description = "Publish all crates to the registry. Requires CARGO_REGISTRY_TOKEN to be set."
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
.editorconfig(1 hunks).github/workflows/publish.yml(1 hunks).releaserc.cjs(1 hunks).releaserc.yml(0 hunks)Cargo.toml(2 hunks)Makefile.toml(2 hunks)contracts/axone-cognitarium/Cargo.toml(1 hunks)contracts/axone-dataverse/Cargo.toml(1 hunks)contracts/axone-law-stone/Cargo.toml(1 hunks)contracts/axone-objectarium/Cargo.toml(1 hunks)packages/axone-cognitarium-client/Cargo.toml(1 hunks)packages/axone-logic-bindings/Cargo.toml(1 hunks)packages/axone-objectarium-client/Cargo.toml(1 hunks)packages/axone-rdf/Cargo.toml(1 hunks)packages/axone-wasm/Cargo.toml(1 hunks)packages/axone-wasm/README.md(1 hunks)packages/testing/Cargo.toml(1 hunks)
💤 Files with no reviewable changes (1)
- .releaserc.yml
✅ Files skipped from review due to trivial changes (6)
- packages/testing/Cargo.toml
- packages/axone-wasm/README.md
- packages/axone-objectarium-client/Cargo.toml
- contracts/axone-law-stone/Cargo.toml
- packages/axone-rdf/Cargo.toml
- packages/axone-cognitarium-client/Cargo.toml
🧰 Additional context used
🪛 actionlint (1.7.4)
.github/workflows/publish.yml
31-31: 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 (15)
.editorconfig (1)
15-18: LGTM: Consistent configuration for .cjs files
The new section maintains consistency with similar configuration files (.yml, .yaml, .json) and supports the migration to .releaserc.cjs.
packages/axone-logic-bindings/Cargo.toml (2)
2-10: LGTM: Proper workspace configuration
Package metadata properly configured for workspace management, with clear description of the package's purpose.
Line range hint 13-20: Verify dependency version management strategy
While most dependencies use workspace versions, form_urlencoded and url use fixed versions. Consider if these should also use workspace versioning for consistency.
✅ Verification successful
Let me check the workspace-level dependency management to make a complete assessment.
Consider keeping form_urlencoded and url dependencies at fixed versions
The current approach appears intentional and correct:
- Both
form_urlencodedandurlare consistently pinned to the same versions (1.2.1and2.5.4respectively) across all packages that use them - These dependencies are not defined in the workspace's shared dependencies, suggesting a deliberate choice to manage them independently
- The consistent versioning across packages indicates careful version control, even without workspace-level management
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if these dependencies are fixed across other packages
echo "Checking form_urlencoded dependency versions:"
rg "form_urlencoded.*=.*" -g 'Cargo.toml'
echo -e "\nChecking url dependency versions:"
rg "url.*=.*" -g 'Cargo.toml'
Length of output: 705
Script:
#!/bin/bash
# Check workspace-level dependency definitions
echo "Checking workspace Cargo.toml for dependency versions:"
cat Cargo.toml
Length of output: 1761
packages/axone-wasm/Cargo.toml (2)
2-10: LGTM: Consistent workspace configuration
Package metadata properly configured for workspace management, with a comprehensive description of the package's URI handling functionality.
Line range hint 13-20: Consider workspace versions for remaining dependencies
Similar to axone-logic-bindings, consider using workspace versions for form_urlencoded and url dependencies if they're used across multiple packages.
.github/workflows/publish.yml (1)
40-44: Verify crate publishing order
The workflow uses cargo make publish-crates but we should verify that crates are published in the correct dependency order.
✅ Verification successful
Let me gather more information about the workspace and dependency structure.
Based on the gathered information, I can now provide the final response:
Crate publishing order is properly handled
The project uses cargo-workspaces (via cargo make publish-crates) which automatically handles dependency order during publishing. The implementation in Makefile.toml shows it uses the --from-git flag which ensures packages are published in the correct dependency order based on the workspace manifest.
The workspace manifest (Cargo.toml) properly defines all dependencies with their workspace inheritance and relative paths, allowing cargo-workspaces to determine the correct publishing order:
- Base packages without internal dependencies (axone-wasm, axone-rdf)
- Core contract packages (axone-objectarium, axone-cognitarium)
- Client libraries and bindings that depend on contracts
- Higher-level contracts that use the client libraries
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if cargo-workspaces is used in the Makefile task
rg -A 5 "publish-crates" Makefile.toml
# Check for workspace dependencies
fd -e toml -x cat {} \; | rg "workspace = true"
Length of output: 4836
Script:
#!/bin/bash
# Check Cargo.toml for workspace members and dependencies
cat Cargo.toml
# Check if cargo-workspaces is installed and its version is specified
rg -A 2 "cargo-workspaces" Cargo.toml
Length of output: 1680
Script:
#!/bin/bash
# Check the publish-crates task implementation in Makefile.toml
cat Makefile.toml
# List all Cargo.toml files to understand the dependency tree
fd Cargo.toml -x echo "=== {}" \; -x cat {}
Length of output: 29267
contracts/axone-objectarium/Cargo.toml (1)
2-10: LGTM! Workspace inheritance is properly configured
The package metadata fields are correctly configured to use workspace inheritance, which aligns with the PR objective of consolidating package metadata.
contracts/axone-dataverse/Cargo.toml (1)
2-10: LGTM! Workspace inheritance is properly configured
The package metadata fields are correctly configured to use workspace inheritance, consistent with the changes in other crates.
Cargo.toml (2)
5-12: LGTM: Workspace package configuration is well-structured
The workspace-level package metadata is properly consolidated, providing consistent values across all crates in the workspace.
26-36: Verify version consistency across workspace
The dependencies are properly configured with consistent version "6.0.0" and correct relative paths. However, let's verify that all crates in the workspace are properly referenced.
✅ Verification successful
Let me generate additional scripts to verify the versions in all Cargo.toml files, particularly focusing on the actual crates mentioned in the dependencies:
Version configuration is correctly implemented using workspace inheritance
All the referenced crates are properly configured to inherit their version from the workspace root (version = { workspace = true }), which is set to "6.0.0". This is the recommended approach for maintaining version consistency across a Rust workspace. The dependency declarations in the root Cargo.toml are also correctly specified with matching versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify all workspace crates are properly referenced
# and have consistent versions
# Check for any Cargo.toml files that might not be referenced
fd -e toml -x echo "Found Cargo.toml: {}" \;
# Verify version consistency
rg -U "version\s*=\s*\"[^\"]+\"" -g "Cargo.toml"
Length of output: 2749
Script:
#!/bin/bash
# Check versions in the specific crate Cargo.toml files
for crate in "./contracts/axone-cognitarium/Cargo.toml" \
"./packages/axone-cognitarium-client/Cargo.toml" \
"./packages/axone-logic-bindings/Cargo.toml" \
"./contracts/axone-objectarium/Cargo.toml" \
"./packages/axone-objectarium-client/Cargo.toml" \
"./packages/axone-rdf/Cargo.toml" \
"./packages/axone-wasm/Cargo.toml"; do
echo "=== $crate ==="
rg "^version\s*=" "$crate" || echo "No version found"
done
Length of output: 3574
.releaserc.cjs (2)
61-62: Verify the release preparation commands
The prepareCmd runs multiple cargo-make commands. Let's ensure these commands are properly defined in the project's Makefile.toml.
✅ Verification successful
All required cargo-make tasks are properly defined
The verification confirms that all three commands (schema, docs-generate, and release-wasm) are properly defined in the root Makefile.toml. Each task has appropriate dependencies and scripts defined:
schemais defined as a workspace-wide taskdocs-generatedepends on prerequisites, docs-clean, and schema tasksrelease-wasmis configured to build optimized wasm using CosmWasm optimizer
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify cargo-make commands exist
# Check if the commands exist in Makefile.toml
echo "Checking for cargo-make tasks:"
fd "Makefile.toml" -x rg -l "schema|docs-generate|release-wasm" {}
Length of output: 644
Script:
#!/bin/bash
# Let's check the root Makefile.toml for these specific tasks
echo "Checking root Makefile.toml for the specific tasks:"
cat Makefile.toml | rg "^\[tasks\.(schema|docs-generate|release-wasm)\]" -A 5
Length of output: 815
69-83: Verify the existence of release assets
Let's ensure all the specified asset paths exist in the project structure.
contracts/axone-cognitarium/Cargo.toml (1)
2-10: LGTM: Package configuration properly aligned with workspace
The package metadata is correctly configured to use workspace values, and the description field provides clear context about the package's purpose.
Makefile.toml (2)
630-634: LGTM: Well-structured installation task
The task follows the established pattern for tool installation tasks in the Makefile, with appropriate version constraints and verification.
647-659: Verify the publishing workflow
The publish-crates task is well-structured with appropriate security measures (CARGO_REGISTRY_TOKEN requirement). However, let's verify the impact of the skip flag.
✅ Verification successful
The skip flag in publish-crates task is safe to use
The codebase analysis shows a well-structured workspace setup where:
- Most packages inherit their version from the workspace (version = { workspace = true })
- The root workspace (Cargo.toml) defines version 6.0.0
- Only the testing package has an explicit version (5.0.0) but it's marked as
publish = false - The cargo-workspaces tool is properly versioned (min_version = "0.3.6")
The skip flag in this context is safe as it only skips the git checks while still respecting the workspace versioning, which is properly configured.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any version-related issues that might be bypassed by the skip flag
# Check for version fields in Cargo.toml files
echo "Checking version fields in Cargo.toml files:"
fd -e toml -x sh -c 'echo "=== {} ==="; cat {} | grep "^version = "'
# Check for workspace dependencies
echo -e "\nChecking workspace dependencies:"
fd Cargo.toml -x sh -c 'echo "=== {} ==="; cat {} | grep -A 5 "\[workspace\]"'
Length of output: 2802
Script:
#!/bin/bash
# Let's check the cargo-workspaces command configuration and usage
# Check if there are any other cargo-workspaces related tasks
echo "Checking cargo-workspaces related tasks:"
rg "cargo.*workspaces" -A 5 -B 5
# Check for version-related configurations
echo -e "\nChecking version configurations in workspace:"
rg "version.*=.*workspace" -A 2 -B 2
# Check for any publish-related configurations
echo -e "\nChecking publish configurations:"
rg "publish.*=.*" -A 2 -B 2
Length of output: 4591
|
@coderabbitai pause |
✅ Actions performedReviews paused. |
ccamel
force-pushed
the
ci/publish
branch
2 times, most recently
from
e3db482 to
f030044
Compare
Addresses #527 by introducing a method to publish crates using cargo-workspaces, a tool that publishes all crates in a workspace in the correct dependency order. This serves as an alternative approach to #569.
Changes Included in This PR
.releaserc.ymlto.releaserc.cjs. This allows for a more specific configuration of the semantic-release-replace-plugin, which is used to update internal dependency versions. While this approach is somewhat more fragile than the one proposed by @amimart in #569, it is simpler and effective. Further refinements can be made if needed.Summary by CodeRabbit
New Features
Bug Fixes
.cjsfiles in the editor configuration.Documentation
axone-wasmpackage to reflect its new focus on CosmWasm URIs.Chores
Cargo.tomlfiles to utilize workspace configurations for various packages.testingpackage from being published.