Rely on linux-packages action for release artefacts - #107
Conversation
Reviewer's GuideThis PR refactors the release pipeline to drop the bespoke nfpm and GoReleaser steps in favor of a shared composite action-driven workflow. The release job is restructured into a matrix-based Class diagram for new build.rs man page staging scriptsclassDiagram
class ComenqBuildScript {
+main()
+copy_man_page() std::io::Result
-manifest_dir: PathBuf
-source: PathBuf
-out_dir: PathBuf
-dest: PathBuf
}
class ComenqdBuildScript {
+main()
+copy_man_page() std::io::Result
-manifest_dir: PathBuf
-source: PathBuf
-out_dir: PathBuf
-dest: PathBuf
}
ComenqBuildScript <|-- ComenqdBuildScript
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Rate limit exceeded@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 25 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (11)
✨ Finishing touches
🧪 Generate unit tests
Comment |
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Pin the shared composite action to a version tag or release rather than a raw commit SHA to make upgrades and readability easier.
- The two crate-specific build.rs files for staging man pages are identical – consider extracting that logic into a shared utility or build script to avoid duplication.
- Add tests for uses_shared_release_actions that cover multiple matrix jobs and different job names to ensure both the build and publish steps are always detected.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Pin the shared composite action to a version tag or release rather than a raw commit SHA to make upgrades and readability easier.
- The two crate-specific build.rs files for staging man pages are identical – consider extracting that logic into a shared utility or build script to avoid duplication.
- Add tests for uses_shared_release_actions that cover multiple matrix jobs and different job names to ensure both the build and publish steps are always detected.
## Individual Comments
### Comment 1
<location> `crates/comenqd/build.rs:6` </location>
<code_context>
+
+fn main() {
+ if let Err(error) = copy_man_page() {
+ panic!("failed to stage man page: {error}");
+ }
+}
</code_context>
<issue_to_address>
**suggestion:** Consider using a more descriptive error message for failed man page staging.
Including the source and destination paths in the panic message will make it easier to identify the cause of the failure.
</issue_to_address>
### Comment 2
<location> `docs/automated-cross-platform-packaging.md:8` </location>
<code_context>
-declaratively defines the build, packaging, and release steps. This file will
-be used by a GitHub Actions workflow that triggers on new git tags.
+daemon for Linux (Fedora, Ubuntu). macOS packaging remains on hold, so the
+workflow focuses on Linux targets only. The current implementation replaces the
+earlier GoReleaser flow with composite actions hosted in
+`leynos/shared-actions`. These actions orchestrate the Rust build, stage the
</code_context>
<issue_to_address>
**issue (review_instructions):** This paragraph exceeds the 80 column wrapping limit for prose.
Please wrap all paragraphs and bullet points to a maximum of 80 columns for improved readability and to comply with documentation standards.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.md`
**Instructions:**
Paragraphs and bullets must be wrapped to 80 columns
</details>
</issue_to_address>
### Comment 3
<location> `docs/automated-cross-platform-packaging.md:22` </location>
<code_context>
+matching man page. The downstream `linux-packages` composite action, executed
+by `rust-build-release`, generates the `nfpm` manifest and packages the staged
+artefacts in one pass. This keeps the workflow lean—only the shared action ever
+executes `nfpm`—and ensures the generated `.deb` and `.rpm` files are ready to
+upload. Finally, `softprops/action-gh-release` publishes the generated packages
+to a draft GitHub Release, preserving the previous workflow's release review
</code_context>
<issue_to_address>
**issue (review_instructions):** This line is part of a paragraph that exceeds the 80 column limit.
Please ensure that all prose is wrapped to 80 columns. This helps maintain consistency and readability in documentation.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.md`
**Instructions:**
Paragraphs and bullets must be wrapped to 80 columns
</details>
</issue_to_address>
### Comment 4
<location> `docs/comenq-design.md:803` </location>
<code_context>
-triggers on version tags to run GoReleaser. It builds Linux packages and
-uploads them to a draft release. Mac support is currently deferred, so the
-workflow targets Linux only.
+To simplify installation, the project now relies on the composite actions
+published in `leynos/shared-actions`. The release workflow iterates over the
+`comenq` client and `comenqd` daemon for both the x86_64 and aarch64 GNU/Linux
</code_context>
<issue_to_address>
**issue (review_instructions):** This paragraph is not wrapped to 80 columns as required.
Please wrap this and all other paragraphs to 80 columns to comply with documentation formatting standards.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.md`
**Instructions:**
Paragraphs and bullets must be wrapped to 80 columns
</details>
</issue_to_address>
### Comment 5
<location> `docs/comenq-design.md:811` </location>
<code_context>
+script copies from `packaging/man`. Packaging responsibility sits entirely with
+the shared `linux-packages` helper invoked by `rust-build-release`; it
+generates the transient `nfpm` manifest and emits `.deb` and `.rpm` artefacts
+for every matrix entry. The workflow uploads those artefacts to a draft GitHub
+Release via `softprops/action-gh-release`, preserving the manual review gate
+that existed in the GoReleaser-based flow. macOS support remains deferred, so
</code_context>
<issue_to_address>
**issue (review_instructions):** This line is part of a paragraph that exceeds the 80 column wrapping limit.
Please ensure all prose is wrapped to 80 columns for consistency and readability.
<details>
<summary>Review instructions:</summary>
**Path patterns:** `**/*.md`
**Instructions:**
Paragraphs and bullets must be wrapped to 80 columns
</details>
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
|
||
| fn main() { | ||
| if let Err(error) = copy_man_page() { | ||
| panic!("failed to stage man page: {error}"); |
There was a problem hiding this comment.
suggestion: Consider using a more descriptive error message for failed man page staging.
Including the source and destination paths in the panic message will make it easier to identify the cause of the failure.
Summary
Testing
https://chatgpt.com/codex/tasks/task_e_68d952556b888322813fde83e70b4217
Summary by Sourcery
Replace the GoReleaser-based packaging step with shared linux-packages composite actions in the GitHub release workflow, update tests to detect the new actions, add man pages and staging scripts for both binaries, and align documentation with the streamlined process
New Features:
Enhancements:
CI:
Documentation:
Tests: