mirror of
https://github.com/bahdotsh/wrkflw.git
synced 2026-09-02 12:16:16 +02:00
b49276a026
The validate subcommand was calling std::process::exit(1) when a directory couldn't be read, which is a rather aggressive response to a permission error. Especially when the code four lines above handles a *missing* path by setting validation_failed and moving on to the next one. Consistency is nice. Let's have some. Split the match from the method chain (because continue is a statement, not an expression, and Rust has opinions about that) and replaced the exit(1) with the same continue pattern. While at it, slap #[must_use] on ContainerOutput so the compiler will yell at anyone who discards a run_container result without checking exit_code. All current callers already bind it, so this is purely forward-looking — but the kind of bug it prevents is the silent-misexecution kind, and those are nobody's favorite.
Wrkflw Crates
This directory contains the Rust crates that make up the Wrkflw project. The project has been restructured to use a workspace-based approach with individual crates for better modularity and maintainability.
Crate Structure
- wrkflw: Main binary crate and entry point for the application
- models: Data models and structures used throughout the application
- evaluator: Workflow evaluation functionality
- executor: Workflow execution engine
- github: GitHub API integration
- gitlab: GitLab API integration
- logging: Logging functionality
- matrix: Matrix-based parallelization support
- parser: Workflow parsing functionality
- runtime: Runtime execution environment
- ui: User interface components
- utils: Utility functions
- validators: Validation functionality
Dependencies
Each crate has its own Cargo.toml file that defines its dependencies. The root Cargo.toml file defines the workspace and shared dependencies.
Build Instructions
To build the entire project:
cargo build
To build a specific crate:
cargo build -p <crate-name>
Testing
To run tests for the entire project:
cargo test
To run tests for a specific crate:
cargo test -p <crate-name>
Rust Best Practices
When contributing to wrkflw, please follow these Rust best practices:
Code Organization
- Place modules in their respective crates to maintain separation of concerns
- Use
pubselectively to expose only the necessary APIs - Follow the Rust module system conventions (use
modandpub modappropriately)
Errors and Error Handling
- Prefer using the
thiserrorcrate for defining custom error types - Use the
?operator for error propagation instead of match statements when appropriate - Implement custom error types that provide context for the error
- Avoid using
.unwrap()and.expect()in production code
Performance
- Profile code before optimizing using tools like
cargo flamegraph - Use
ArcandMutexjudiciously for shared mutable state - Leverage Rust's zero-cost abstractions (iterators, closures)
- Consider adding benchmark tests using the
criterioncrate for performance-critical code
Security
- Validate all input, especially from external sources
- Avoid using
unsafecode unless absolutely necessary - Handle secrets securely using environment variables
- Check for integer overflows with
checked_operations
Testing
- Write unit tests for all public functions
- Use integration tests to verify crate-to-crate interactions
- Consider property-based testing for complex logic
- Structure tests with clear preparation, execution, and verification phases
Tooling
- Run
cargo clippybefore committing changes to catch common mistakes - Use
cargo fmtto maintain consistent code formatting - Enable compiler warnings with
#![warn(clippy::all)]
For more detailed guidance, refer to the project's best practices documentation.