Add man page generation to release workflow #343
Conversation
Reviewer's GuideThis PR integrates a Clap-based CLI into the Class diagram for new CLI struct and usageclassDiagram
class Cli {
+Option<String> name
}
Cli : +parse_from(args)
Cli : +parse()
main --> Cli : uses
build.rs --> Cli : imports
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbit
WalkthroughAdd a Clap-based CLI with an optional --name flag, integrate man page generation via build.rs, update Cargo dependencies and features, add docs, and introduce a GitHub Actions release workflow that builds in release mode and uploads the generated man page asset. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant User
participant CLI as wireframe (main)
participant Parser as Clap Parser
Note over CLI,Parser: Runtime CLI flow
User->>CLI: Run `wireframe [--name NAME]`
CLI->>Parser: Cli::parse()
Parser-->>CLI: Cli { name: Option<String> }
alt name provided
CLI->>User: Print "Hello, {name} from Wireframe!"
else no name
CLI->>User: Print "Hello from Wireframe!"
end
sequenceDiagram
autonumber
participant GH as GitHub Release Event
participant CI as Actions Job (build)
participant Cargo as Cargo build.rs
participant Gen as clap_mangen
participant Rel as Release Upload
Note over GH,CI: Release published -> Workflow
GH->>CI: Trigger on release.published
CI->>CI: Checkout, setup Rust, env BUILD_PROFILE=release
CI->>CI: make release
CI->>Cargo: Build (runs build.rs)
Cargo->>Gen: Generate man from Cli::command()
Gen-->>Cargo: wireframe.1 (buffer)
Cargo->>CI: Write target/generated-man/wireframe.1
CI->>Rel: Upload asset wireframe.1 to release
Rel-->>CI: Asset attached
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| - name: Build | ||
| run: make release | ||
| - name: Upload release assets | ||
| uses: softprops/action-gh-release@v2 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
Blocking issues:
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
General comments:
- In build.rs, consider using the standard OUT_DIR environment variable instead of hard-coding "target/generated-man" so generated files end up in the normal build output path.
- You’ve declared clap twice (in both [dependencies] and [build-dependencies]); consolidating or aligning them via a workspace dependency could prevent version drift.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- In build.rs, consider using the standard OUT_DIR environment variable instead of hard-coding "target/generated-man" so generated files end up in the normal build output path.
- You’ve declared clap twice (in both [dependencies] and [build-dependencies]); consolidating or aligning them via a workspace dependency could prevent version drift.
## Individual Comments
### Comment 1
<location> `build.rs:8` </location>
<code_context>
+use clap::CommandFactory;
+use clap_mangen::Man;
+
+#[path = "src/cli.rs"]
+mod cli;
+
</code_context>
<issue_to_address>
Consider moving the CLI definition to the library and writing directly to the file to simplify build script logic.
Here’s one way to both remove the `#[path]` hack and simplify the write‐buffer dance, while keeping the exact same output:
1. Move your CLI definition into your library (`src/lib.rs`) so it can be used by both `main.rs` and `build.rs`:
```rust
// src/lib.rs
use clap::CommandFactory;
mod cli;
pub use cli::Cli;
/// convenience constructor for build.rs
pub fn build_cli() -> clap::Command {
Cli::command()
}
```
2. In `build.rs`, import that function instead of shimming `src/cli.rs`, and write directly into the file:
```rust
// build.rs
use std::{fs, path::PathBuf};
use clap_mangen::Man;
// import your crate as a library
use mycrate::build_cli;
fn main() -> Result<(), Box<dyn std::error::Error>> {
println!("cargo:rerun-if-changed=src/cli.rs");
let out_dir = PathBuf::from("target/generated-man");
fs::create_dir_all(&out_dir)?;
let mut file = fs::File::create(out_dir.join("wireframe.1"))?;
Man::new(build_cli()).render(&mut file)?;
Ok(())
}
```
Now you’ve
- eliminated the `#[path]` shim
- removed the intermediate `Vec<u8>`
- kept all functionality intact and still auto‐regenerate on CLI changes.
</issue_to_address>
## Security Issues
### Issue 1
<location> `.github/workflows/release.yml:22` </location>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| use clap::CommandFactory; | ||
| use clap_mangen::Man; | ||
|
|
||
| #[path = "src/cli.rs"] |
There was a problem hiding this comment.
issue (complexity): Consider moving the CLI definition to the library and writing directly to the file to simplify build script logic.
Here’s one way to both remove the #[path] hack and simplify the write‐buffer dance, while keeping the exact same output:
- Move your CLI definition into your library (
src/lib.rs) so it can be used by bothmain.rsandbuild.rs:
// src/lib.rs
use clap::CommandFactory;
mod cli;
pub use cli::Cli;
/// convenience constructor for build.rs
pub fn build_cli() -> clap::Command {
Cli::command()
}- In
build.rs, import that function instead of shimmingsrc/cli.rs, and write directly into the file:
// build.rs
use std::{fs, path::PathBuf};
use clap_mangen::Man;
// import your crate as a library
use mycrate::build_cli;
fn main() -> Result<(), Box<dyn std::error::Error>> {
println!("cargo:rerun-if-changed=src/cli.rs");
let out_dir = PathBuf::from("target/generated-man");
fs::create_dir_all(&out_dir)?;
let mut file = fs::File::create(out_dir.join("wireframe.1"))?;
Man::new(build_cli()).render(&mut file)?;
Ok(())
}Now you’ve
- eliminated the
#[path]shim - removed the intermediate
Vec<u8> - kept all functionality intact and still auto‐regenerate on CLI changes.
| - name: Build | ||
| run: make release | ||
| - name: Upload release assets | ||
| uses: softprops/action-gh-release@v2 |
There was a problem hiding this comment.
security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha): An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
Source: opengrep
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
Codex Review: Here are some suggestions.
Reply with @codex fix comments to fix any unresolved comments.
About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you open a pull request for review, mark a draft as ready, or comment "@codex review". If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex fix this CI failure" or "@codex address that feedback".
| let out_dir = PathBuf::from("target/generated-man"); | ||
| fs::create_dir_all(&out_dir)?; | ||
|
|
||
| let cmd = cli::Cli::command(); | ||
| let man = Man::new(cmd); | ||
| let mut buf: Vec<u8> = Vec::new(); | ||
| man.render(&mut buf)?; |
There was a problem hiding this comment.
[P1] Avoid writing build output into crate sources
The build script writes the generated man page to target/generated-man under the crate root. That path is writable in this repo, but build scripts also run when the crate is compiled as a dependency from crates.io, where the source directory is read-only. Creating or writing files there will fail and prevent dependent builds from succeeding. Build scripts should use the OUT_DIR provided by Cargo (and copy the resulting file in the release workflow if a stable path is required) so compilation works in all environments.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
💡 Knowledge Base configuration:
- Jira integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (7)
.github/workflows/release.yml(1 hunks)Cargo.toml(2 hunks)build.rs(1 hunks)docs/cli.md(1 hunks)docs/contents.md(1 hunks)src/cli.rs(1 hunks)src/main.rs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
Cargo.toml
📄 CodeRabbit inference engine (AGENTS.md)
Cargo.toml: Use explicit version ranges in Cargo.toml; keep dependencies up to date
All dependencies in Cargo.toml must use caret (^) SemVer-compatible requirements (e.g., "1.2.3")
Forbid wildcard (*) and open-ended (>=) versions; use ~ only with a specific documented reason
Files:
Cargo.toml
docs/**/*.md
📄 CodeRabbit inference engine (docs/documentation-style-guide.md)
docs/**/*.md: Use British English based on the Oxford English Dictionary (en-oxendict) for documentation text.
The word "outwith" is acceptable in documentation.
Keep US spelling when used in an API, for examplecolor.
Use the Oxford comma in documentation text.
Treat company names as collective nouns in documentation (e.g., "Lille Industries are expanding").
Write headings in sentence case in documentation.
Use Markdown headings (#,##,###, etc.) in order without skipping levels.
Follow markdownlint recommendations for Markdown files.
Provide code blocks and lists using standard Markdown syntax.
Always provide a language identifier for fenced code blocks; useplaintextfor non-code text.
Use-as the first level bullet and renumber lists when items change.
Prefer inline links using[text](url)or angle brackets around the URL; avoid reference-style links like[foo][bar].
Ensure blank lines before and after bulleted lists and fenced blocks in Markdown.
Ensure tables have a delimiter line below the header row in Markdown.
Expand any uncommon acronym on first use, for example, Continuous Integration (CI).
Wrap paragraphs at 80 columns in documentation.
Wrap code at 120 columns in documentation.
Do not wrap tables in documentation.
Use sequentially numbered footnotes referenced with[^1]and place definitions at the end of the file.
Where it adds clarity, include Mermaid diagrams in documentation.
When embedding figures, useand provide concise alt text describing the content.
Add a brief description before each Mermaid diagram in documentation for screen readers.Document examples showing how to deprecate old message versions gracefully
docs/**/*.md: Use docs/ markdown as the source of truth for requirements and decisions
Proactively update docs/ when requirements, dependencies, or architecture change
Documentation must use en-GB-oxendict spelling and grammar (LICENSE name exempt)When long lines are warranted in ...
Files:
docs/cli.mddocs/contents.md
**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
**/*.md: Markdown paragraphs and bullet points must be wrapped at 80 columns
Markdown code blocks must be wrapped at 120 columns
Do not wrap tables and headings in Markdown
Use dashes (-) for list bullets in Markdown
Use GitHub-flavoured Markdown footnotes ([^1])
Files:
docs/cli.mddocs/contents.md
⚙️ CodeRabbit configuration file
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/cli.mddocs/contents.md
docs/**
📄 CodeRabbit inference engine (docs/wireframe-1-0-detailed-development-roadmap.md)
docs/**: Document async-stream as the canonical way to create streams imperatively
Write comprehensive user guides for Duplex Messaging & Pushes, Streaming Responses, and Message Fragmentation with runnable examples
Files:
docs/cli.mddocs/contents.md
**/*.rs
📄 CodeRabbit inference engine (AGENTS.md)
**/*.rs: Use precise names; boolean names should start with is/has/should
Use en-GB-oxendict spelling and grammar in comments
Function documentation must include clear examples; test documentation should omit redundant examples
Keep code files ≤ 400 lines; split long switch/dispatch logic by feature; move large test data to external files
Disallow Clippy warnings
Fix warnings emitted during tests in code rather than silencing them
Extract helper functions for long functions; adhere to separation of concerns and CQRS
Group related parameters into meaningful structs when functions have many parameters
Consider using Arc for large error returns to reduce data size
Each Rust module must begin with a module-level //! comment describing purpose and utility
Document public APIs with Rustdoc /// comments to enable cargo doc generation
Prefer immutable data; avoid unnecessary mut
Handle errors with Result instead of panicking where feasible
Avoid unsafe code unless necessary and document any usage clearly
Place function attributes after doc comments
Do not use return in single-line functions
Use predicate functions for conditional criteria with more than two branches
Do not silence lints except as a last resort
Lint suppressions must be tightly scoped and include a clear reason
Prefer #[expect(..)] over #[allow(..)] for lints
Prefer .expect() over .unwrap()
Use concat!() to combine long string literals rather than escaping newlines
Prefer single-line function bodies where appropriate (e.g., pub fn new(id: u64) -> Self { Self(id) })
Prefer semantic error enums deriving std::error::Error via thiserror for inspectable conditions
Files:
src/main.rsbuild.rssrc/cli.rs
⚙️ CodeRabbit configuration file
**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.
Adhere to single responsibility and CQRS
Place function attributes after doc comments.
Do not use
returnin single-line functions.Move conditionals with >2 branches into a predicate function.
Avoid
unsafeunless absolutely necessary.Every module must begin with a
//!doc comment that explains the module's purpose and utility.Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar
Lints must not be silenced except as a last resort.
#[allow]is forbidden.- Only narrowly scoped
#[expect(lint, reason = "...")]is allowed.- No lint groups, no blanket or file-wide suppression.
- Include
FIXME:with link if a fix is expected.Where code is only used by specific features, it must be conditionally compiled or a conditional expectation for unused_code applied.
Use
rstestfixtures for shared setup and to avoid repetition between tests.Replace duplicated tests with
#[rstest(...)]parameterised cases.Prefer
mockallfor mocks/stubs.Prefer
.expect()over.unwrap()Ensure that any API or behavioural changes are reflected in the documentation in
docs/Ensure that any completed roadmap steps are recorded in the appropriate roadmap in
docs/Files must not exceed 400 lines in length
- Large modules must be decomposed
- Long match statements or dispatch tables should be decomposed by domain and collocated with targets
- Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.
Environment access (env::set_var and env::remove_var) are always unsafe in Rust 2024 and MUST be marked as such
- For testing of functionality depending upon environment variables, dependency injection and the
mockablecrate are the preferred option.- If mockable cannot be used, env mutations in tests ...
Files:
src/main.rsbuild.rssrc/cli.rs
{src,tests}/**/*.rs
📄 CodeRabbit inference engine (AGENTS.md)
Write unit and behavioural tests for new functionality
Files:
src/main.rssrc/cli.rs
{src/main.rs,src/bin/**/*.rs}
📄 CodeRabbit inference engine (AGENTS.md)
Use an opaque error (eyre::Report) only at the app boundary (main entrypoints/top-level tasks) for human-readable logs
Files:
src/main.rs
🧬 Code graph analysis (2)
src/main.rs (1)
build.rs (1)
main(11-24)
build.rs (1)
src/main.rs (1)
main(9-20)
🪛 LanguageTool
docs/cli.md
[style] ~4-~4: Would you like to use the Oxford spelling “customizing”? The spelling ‘customising’ is also correct.
Context: ...ments. An optional --name flag allows customising the greeting printed by the wireframe...
(OXFORD_SPELLING_Z_NOT_S)
🪛 GitHub Check: CodeQL
.github/workflows/release.yml
[warning] 22-22: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release' step Uses Step uses 'softprops/action-gh-release' with ref 'v2', not a pinned commit hash
🔍 Remote MCP
Here are a few concrete references to help validate the new man‐page generation and release steps:
• The build script’s use of clap_mangen::Man to generate a ROFF man page follows the crate’s documented pattern:
let man = clap_mangen::Man::new(cmd);
let mut buffer = Vec::new();
man.render(&mut buffer)?;
std::fs::write("target/generated-man/wireframe.1", buffer)?;– this matches the example in the clap_mangen docs
Version 0.2.x (latest 0.2.29) is the current release series for clap_mangen
• Uploading the generated man page via softprops/action-gh-release@v2 with:
with:
files: target/generated-man/wireframe.1is consistent with the action’s single-asset example, which accepts a newline-delimited glob or filename
• The action requires permissions: contents: write. Note the docs’ caution that on release events (on: release: types: [published]), the default GITHUB_TOKEN won’t trigger follow-on workflows, so if you need downstream workflows, a personal access token would be required
• The Rust setup step uses a composite “Setup Rust” action from leynos/shared-actions pinned to commit 8470c10… (v1). Reviewing that action will confirm which toolchain version, caching behavior, and Cargo config it applies
⏰ Context from checks skipped due to timeout of 120000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build-test
🔇 Additional comments (5)
docs/contents.md (1)
64-65: Add CLI entry — LGTMEntry reads well, follows list style and en‑GB spelling.
Run the checks to ensure the linked document exists, starts with a level‑1 heading, and mentions man‑page generation.
#!/bin/bash set -euo pipefail # 1) Verify target file exists fd -t f '^cli\.md$' docs # 2) Verify it starts with a level-1 heading rg -n "^# " docs/cli.md | sed -n '1p' # 3) Verify it references man page/gen rg -n -i 'man page|man-page|manual page|clap_mangen' docs/cli.md # 4) Check for lines >80 cols (MD013 exceptions aside) awk 'length($0)>80{print FILENAME ":" NR ":" length($0) " cols"; exit 0}' docs/cli.md || echo "OK: <=80 cols"build.rs (1)
1-24: Man‑page generation script — LGTMCorrectly reuses CLI definition, sets rerun trigger, and writes to a stable path for release uploads.
src/cli.rs (1)
17-28: Unit test — LGTMTest is clear and minimal; no redundancy.
src/main.rs (1)
3-19: CLI integration — LGTMEntry point initialises logging, parses args, and prints deterministically.
.github/workflows/release.yml (1)
22-25: Pin softprops/action-gh-release to immutable commit- - uses: softprops/action-gh-release@v2 + - uses: softprops/action-gh-release@72f2c25fcb47643c292f7107632f7a47c1df5cd8
| CARGO_TERM_COLOR: always | ||
| BUILD_PROFILE: release | ||
| steps: | ||
| - uses: actions/checkout@v5 |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Pin actions/checkout to a commit SHA.
Apply the same immutability policy to first‑party actions.
- - uses: actions/checkout@v5
+ - uses: actions/checkout@<COMMIT_SHA_FOR_V5>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v5 | |
| - uses: actions/checkout@<COMMIT_SHA_FOR_V5> |
🤖 Prompt for AI Agents
In .github/workflows/release.yml at line 16, the workflow uses
actions/checkout@v5 which is a floating tag; replace it with an immutable commit
SHA for that action. Update the uses entry to the specific full commit SHA of
actions/checkout (e.g., actions/checkout@<commit-sha>) so the workflow is pinned
to a fixed version, ensuring immutability and reproducible runs.
| - name: Build | ||
| run: make release | ||
| - name: Upload release assets | ||
| uses: softprops/action-gh-release@v2 | ||
| with: | ||
| files: | | ||
| target/generated-man/wireframe.1 |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Fail fast if the man page was not generated.
Add an existence check before the upload to surface build.rs or Makefile
issues early.
- name: Build
run: make release
+ - name: Verify generated man page exists
+ run: |
+ test -s target/generated-man/wireframe.1 \
+ || { echo "wireframe.1 missing"; exit 1; }
- name: Upload release assets
uses: softprops/action-gh-release@v2
with:
files: |
target/generated-man/wireframe.1#!/bin/bash
# Search for man page references
rg -n 'wireframe\.1' -n .
# Search for generated-man directory usage
rg -n 'generated-man' -n .
# Show Makefile rules for man page generation
fd '^Makefile$' -x sed -n '1,200p' Makefile
# Inspect build.rs if present for man page creation logic
fd 'build.rs' -x sed -n '1,200p' build.rs🏁 Script executed:
#!/usr/bin/env bash
# Locate references to the generated man page
rg -n 'wireframe\.1' .
rg -n 'generated-man' .
# Inspect Makefile for man page generation rules
if [ -f Makefile ]; then
sed -n '1,200p' Makefile
fi
# Inspect build.rs for man page creation logic
if [ -f build.rs ]; then
sed -n '1,200p' build.rs
fiLength of output: 2719
Fail fast if generated man page is missing
Add a check after the build step to abort if target/generated-man/wireframe.1 is absent or empty.
- name: Build
run: make release
+ - name: Verify generated man page exists
+ run: |
+ test -s target/generated-man/wireframe.1 \
+ || { echo "wireframe.1 missing"; exit 1; }
- name: Upload release assets
uses: softprops/action-gh-release@v2
with:
files: |
target/generated-man/wireframe.1🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 22-22: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Release' step Uses Step uses 'softprops/action-gh-release' with ref 'v2', not a pinned commit hash
🤖 Prompt for AI Agents
.github/workflows/release.yml around lines 19 to 25: the workflow proceeds to
upload the generated man page without verifying it exists or is non-empty; add a
new step immediately after the Build step that runs a shell check to fail-fast
if target/generated-man/wireframe.1 is missing or zero-length (use test -s or
equivalent) and exit with a clear error message so the workflow aborts before
the upload step.
| let out_dir = PathBuf::from("target/generated-man"); | ||
| fs::create_dir_all(&out_dir)?; | ||
|
|
||
| let cmd = cli::Cli::command(); | ||
| let man = Man::new(cmd); | ||
| let mut buf: Vec<u8> = Vec::new(); | ||
| man.render(&mut buf)?; | ||
| fs::write(out_dir.join("wireframe.1"), buf)?; | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Verify release workflow builds before upload
Ensure the release workflow compiles the crate (thus running build.rs) and uploads the expected artefact path.
Execute:
#!/bin/bash
set -euo pipefail
# Find release workflows
fd -t f -g ".github/workflows/*.yml" -x sh -c '
echo "== {} ==";
rg -n "cargo build" {} || true;
rg -n "files:\s*target/generated-man/wireframe\.1" {} || true;
rg -n "permissions:\s*[\r\n]+(\s*)contents:\s*write" {} || true
'If the upload happens in a matrix or multi‑job workflow, gate the upload with needs: build and a path existence check to fail fast when the man page is missing.
🤖 Prompt for AI Agents
In build.rs around lines 14 to 22 the build script writes a generated man page
to target/generated-man/wireframe.1 but the release workflow may not run cargo
build (so build.rs won't execute) or may upload the wrong artifact path; update
the release workflow(s) to run cargo build (or cargo build --release) before the
upload step, ensure the upload 'files:' entry references
target/generated-man/wireframe.1 exactly, grant the workflow job
permissions.contents: write if using the actions/upload-release-asset action,
and if uploads run in a matrix or separate job, add needs: build and a
pre-upload check (fail-fast) that the file exists at
target/generated-man/wireframe.1 so the release job is skipped/failed if the man
page is missing.
| metrics-exporter-prometheus = { version = "0.17.2", optional = true, features = ["http-listener"] } | ||
| thiserror = "2.0.16" | ||
| static_assertions = "1" | ||
| clap = { version = "4.5", features = ["derive"] } |
There was a problem hiding this comment.
Use caret requirements per dependency policy
Adopt caret SemVer ranges for new deps per repository rules.
Apply:
-clap = { version = "4.5", features = ["derive"] }
+clap = { version = "^4.5", features = ["derive"] }-[build-dependencies]
-clap = { version = "4.5", features = ["derive"] }
-clap_mangen = "0.2"
+[build-dependencies]
+clap = { version = "^4.5", features = ["derive"] }
+clap_mangen = "^0.2"Also applies to: 67-70
🤖 Prompt for AI Agents
In Cargo.toml around line 41 (and also lines 67-70), the dependency entries use
exact version strings; update them to use caret SemVer ranges per repo policy
(e.g., change version = "4.5" to version = "^4.5" or "^4.5.0" and apply the same
caret style to the dependencies on lines 67-70), keeping existing feature flags
intact.
| Wireframe includes a small command line interface for demonstration. The CLI | ||
| uses `clap` to parse arguments. An optional `--name` flag allows customising | ||
| the greeting printed by the `wireframe` binary. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Adopt Oxford -ize spelling and wrap to 80 columns.
Replace -ise with -ize and reflow to respect the docs wrapping rule.
- Wireframe includes a small command line interface for demonstration. The CLI
- uses `clap` to parse arguments. An optional `--name` flag allows customising
- the greeting printed by the `wireframe` binary.
+ Wireframe includes a small command line interface for demonstration. The
+ CLI uses `clap` to parse arguments. An optional `--name` flag allows
+ customizing the greeting printed by the `wireframe` binary.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Wireframe includes a small command line interface for demonstration. The CLI | |
| uses `clap` to parse arguments. An optional `--name` flag allows customising | |
| the greeting printed by the `wireframe` binary. | |
| Wireframe includes a small command line interface for demonstration. The | |
| CLI uses `clap` to parse arguments. An optional `--name` flag allows | |
| customizing the greeting printed by the `wireframe` binary. |
🧰 Tools
🪛 LanguageTool
[style] ~4-~4: Would you like to use the Oxford spelling “customizing”? The spelling ‘customising’ is also correct.
Context: ...ments. An optional --name flag allows customising the greeting printed by the wireframe...
(OXFORD_SPELLING_Z_NOT_S)
🤖 Prompt for AI Agents
In docs/cli.md around lines 3 to 5, the text uses British -ise spelling and
exceeds the 80-column docs wrap rule; update occurrences of "-ise" to "-ize"
(e.g., "customising" → "customizing") and reflow the paragraph so no line
exceeds 80 characters while preserving sentence structure and punctuation.
| Manual pages are generated during the build via `clap_mangen`. The `build.rs` | ||
| script writes `wireframe.1` to `target/generated-man`, and the `release` GitHub | ||
| workflow uploads this file. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Link libraries inline and keep lines ≤80 chars.
Add inline links and reflow.
- Manual pages are generated during the build via `clap_mangen`. The `build.rs`
- script writes `wireframe.1` to `target/generated-man`, and the `release` GitHub
- workflow uploads this file.
+ Manual pages are generated during the build via
+ [`clap_mangen`](https://crates.io/crates/clap_mangen). The `build.rs` script
+ writes `wireframe.1` to `target/generated-man`, and the `release` GitHub
+ workflow uploads this file.Add a minimal usage block after this paragraph:
```sh
# Run the CLI
cargo run -- -n Alice
# View the generated man page locally
man -l target/generated-man/wireframe.1
<details>
<summary>🤖 Prompt for AI Agents</summary>
In docs/cli.md around lines 7-9, the paragraph about manual page generation
needs inline links and reflow to 80 chars or less; replace bare clap_mangen
and release references with inline Markdown links to their respective
docs/repos, rewrap the sentence to keep each line ≤80 chars, and then insert a
minimal usage block immediately after the paragraph containing the
two-shell-command example that shows running the CLI (cargo run -- -n Alice) and
viewing the generated man page (man -l target/generated-man/wireframe.1).
</details>
<!-- fingerprinting:phantom:triton:chinchilla -->
<!-- This is an auto-generated comment by CodeRabbit -->
| //! Command line interface for the wireframe example binary. | ||
| //! | ||
| //! Provides a tiny CLI to demonstrate argument parsing and man page | ||
| //! generation. | ||
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Tighten module docs to en‑GB hyphenation
Hyphenate “command‑line” in line with house style.
-//! Command line interface for the wireframe example binary.
+//! Command‑line interface for the Wireframe example binary.
//!
-//! Provides a tiny CLI to demonstrate argument parsing and man page
-//! generation.
+//! Provides a tiny CLI to demonstrate argument parsing and man‑page generation.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| //! Command line interface for the wireframe example binary. | |
| //! | |
| //! Provides a tiny CLI to demonstrate argument parsing and man page | |
| //! generation. | |
| //! Command-line interface for the Wireframe example binary. | |
| // | |
| //! Provides a tiny CLI to demonstrate argument parsing and man-page generation. |
🤖 Prompt for AI Agents
In src/cli.rs around lines 1 to 5, the module doc comment uses "Command line"
but our house style requires the en‑GB hyphenated form "Command-line"; update
the top doc line to read "Command-line interface for the wireframe example
binary." and ensure any other instances in this doc block follow the same
hyphenation.
| /// Command line arguments for the `wireframe` binary. | ||
| #[derive(Debug, Parser)] | ||
| #[command(name = "wireframe", version, about = "Example Wireframe binary")] | ||
| pub struct Cli { | ||
| /// Name to greet. | ||
| #[arg(short, long)] | ||
| pub name: Option<String>, | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Document a usage example in Rustdoc
Add a minimal example to aid cargo doc readers.
/// Command line arguments for the `wireframe` binary.
#[derive(Debug, Parser)]
#[command(name = "wireframe", version, about = "Example Wireframe binary")]
pub struct Cli {
@@
pub name: Option<String>,
}
+
+/// # Examples
+/// Run with a name:
+/// ```shell
+/// wireframe --name Sam
+/// ```🤖 Prompt for AI Agents
In src/cli.rs around lines 8 to 15, add a Rustdoc usage example above the Cli
struct: include a short Examples section with a fenced shell code block showing
the command invocation (e.g., wireframe --name Sam) so cargo doc renders a
minimal usage example; ensure the example is in Rustdoc comment form (///) and
uses a ```sh fenced block.
1 participant
Summary
wireframe.1Testing
make fmtmake lintmake testmake markdownlintmake nixie(fails: KeyboardInterrupt)https://chatgpt.com/codex/tasks/task_e_68b4f9934dc88322963a8e1ec67afe1d
Summary by Sourcery
Introduce a Clap-based CLI with optional name flag for the wireframe binary, generate a manual page via a build script, update documentation, and extend the release workflow to upload the generated man page.
New Features:
Enhancements:
Build:
CI:
Documentation:
Tests: