refactor: switch to workspace layout (#792)

This commit is contained in:
William Woodruff 2025-05-13 21:29:19 -04:00 committed by GitHub
parent 4dbc900924
commit 19b6bd6cc1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
268 changed files with 98 additions and 86 deletions

View file

@ -254,12 +254,12 @@ Some things that can be useful to discuss beforehand:
When developing a new `zizmor` audit, there are a couple of implementation details to be aware of:
- All existing audits live in a Rust modules grouped under `src/audit` folder
- The expected behavior for all audits is defined by the `Audit` trait at `src/audit/mod.rs`
- The expected outcome of an executed audit is defined by the `Finding` struct at `src/finding/mod.rs`
- Any `Audit` implementation can have access to an `AuditState` instance, as per `src/state.rs`
- If an audit requires data from the GitHub API, there is a `Client` implementation at `src/github_api.rs`
- All the audits must be registered at `src/main.rs` according to the `register_audit!` macro
- All existing audits live in a Rust modules grouped under `crates/zizmor/src/audit` folder
- The expected behavior for all audits is defined by the `Audit` trait at `crates/zizmor/src/audit/mod.rs`
- The expected outcome of an executed audit is defined by the `Finding` struct at `crates/zizmor/src/finding/mod.rs`
- Any `Audit` implementation can have access to an `AuditState` instance, as per `crates/zizmor/src/state.rs`
- If an audit requires data from the GitHub API, there is a `Client` implementation at `crates/zizmor/src/github_api.rs`
- All the audits must be registered at `crates/zizmor/src/main.rs` according to the `register_audit!` macro
Last but not least, it's useful to run the following checks before opening a Pull Request:
@ -286,14 +286,14 @@ cargo test
The general procedure for adding a new audit can be described as:
- Define a new file at `src/audit/my_new_audit.rs`
- Define a new file at `crates/zizmor/src/audit/my_new_audit.rs`
- Define a struct like `MyNewAudit`
- Use the `audit_meta!` macro to implement `AuditCore` for `MyNewAudit`
- Implement the `Audit` trait for `MyNewAudit`
- You may want to use both the `AuditState` and `github_api::Client` to get the job done
- Assign the proper `location` when creating a `Finding`, grabbing it from the
proper `Workflow`, `Job` or `Step` instance
- Register `MyNewAudit` in the known audits at `src/main.rs`
- Register `MyNewAudit` in the known audits at `crates/zizmor/src/main.rs`
- Add proper integration tests covering some scenarios at `tests/acceptance.rs`
- Add proper docs for this new audit at `docs/audits`. Take care to add your new
heading in alpha order relative to the other audit headings. Please include
@ -325,7 +325,7 @@ working as expected.
The general procedure for changing an existing audit is:
- Locate the existing audit file at `src/audit`
- Locate the existing audit file at `crates/zizmor/src/audit`
- Change the behaviour to match new requirements there (e.g. consuming a new CLI info exposed through `AuditState`)
- Ensure that tests and samples at `tests/` reflect changed behaviour accordingly (e.g. the confidence for finding has changed)
- Ensure that `docs/audits` reflect changed behaviour accordingly (e.g. an audit that is no longer pedantic)