[rust-guard] Rust Guard: gate has_approval_label / has_promotion_label / has_demotion_label with #[cfg(test)]

[github-actions]

🦀 Rust Guard Improvement Report

Improvement 1: Gate three test-only pub functions with #[cfg(test)]

Category: API Surface
File(s): guards/github-guard/rust-guard/src/labels/helpers.rs, guards/github-guard/rust-guard/src/labels/mod.rs
Effort: Small (< 15 min)
Risk: Low

Problem

Three functions in helpers.rs are declared pub but are only ever called from test code:

Function	Line	Current visibility
has_approval_label	409	pub fn
has_promotion_label	510	pub fn
has_demotion_label	516	pub fn

Their sibling has_refusal_label (line 432) is already correctly gated with #[cfg(test)]. All three functions above are re-exported from mod.rs only inside its #[cfg(test)] block (lines 53–54 of mod.rs), yet the definitions themselves lack the gate. This inconsistency widens the compiled WASM surface and misleads readers into thinking these predicates are part of the production API.

The production code never calls has_approval_label directly — it goes through the private helper first_matching_approval_label instead. Similarly, has_promotion_label and has_demotion_label are called only from within helpers.rs itself (apply_promotion_label_promotion / apply_demotion_label_demotion) and from mod.rs tests.

Suggested Change

Add #[cfg(test)] to all three function definitions, mirroring the existing pattern for has_refusal_label.

Before

// helpers.rs, line 409
pub fn has_approval_label(item: &Value, ctx: &PolicyContext) -> bool {
    first_matching_approval_label(item, ctx).is_some()
}

// helpers.rs, line 510
pub fn has_promotion_label(item: &Value, ctx: &PolicyContext) -> bool {
    item_has_config_label(item, &ctx.promotion_label)
}

// helpers.rs, line 516
pub fn has_demotion_label(item: &Value, ctx: &PolicyContext) -> bool {
    item_has_config_label(item, &ctx.demotion_label)
}

After

// helpers.rs, line 409
#[cfg(test)]
pub fn has_approval_label(item: &Value, ctx: &PolicyContext) -> bool {
    first_matching_approval_label(item, ctx).is_some()
}

// helpers.rs, line 510
#[cfg(test)]
pub fn has_promotion_label(item: &Value, ctx: &PolicyContext) -> bool {
    item_has_config_label(item, &ctx.promotion_label)
}

// helpers.rs, line 516
#[cfg(test)]
pub fn has_demotion_label(item: &Value, ctx: &PolicyContext) -> bool {
    item_has_config_label(item, &ctx.demotion_label)
}

No changes needed in mod.rs — its #[cfg(test)] pub(crate) use helpers::{..., has_approval_label, has_demotion_label, has_promotion_label, ...} re-exports are already gated.

Verification

cargo test --target wasm32-wasip1 2>&1 | grep -E "FAILED|ok"
# All tests should still pass

cargo build --target wasm32-wasip1 --release 2>&1
# Production build should succeed (functions removed from non-test compilation)

Why This Matters

• Consistency: has_refusal_label already has #[cfg(test)] — these three should match
• Smaller WASM binary: Test-only symbols are excluded from release builds
• Clearer API contract: Readers can immediately see these are test utilities, not production predicates
• No dead-code warnings risk: A future linter pass won't flag these as unused pub symbols in production builds

---

Codebase Health Summary

• Total Rust files: 10
• Total lines: 18,371
• Areas analyzed: lib.rs, tools.rs, labels/helpers.rs, labels/mod.rs, labels/tool_rules.rs, labels/response_items.rs, labels/response_paths.rs, labels/backend.rs, labels/constants.rs
• Areas with no further improvements: labels/constants.rs (only constants, well-organized), tools.rs (already well-scoped after recent is_lock_operation/is_unlock_operation fix)

---

Generated by Rust Guard Improver • Run: §29405404976

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Rust Guard Improver · 96.6 AIC · ⊞ 6.4K · ◷

• expires on Jul 22, 2026, 9:48 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

Thank you for this thorough analysis! Looking at the current codebase:

• has_approval_label (line 408): already has #[cfg(test)] — this improvement has already been applied ✅
• has_promotion_label and has_demotion_label (lines 510, 516): these are called from production code at lines 529 and 556 (apply_promotion_label_promotion / apply_demotion_label_demotion), so gating them with #[cfg(test)] would cause a compile error. They cannot be test-only.

The mod.rs re-exports already live inside a #[cfg(test)] block, which is correct since those re-exports serve tests in other modules.

In summary: the one actionable change from this report has already been applied. The remaining two functions are production predicates — the analysis was likely based on an older snapshot of the file.

Warning

Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• awmgmcpg
• proxy.golang.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"
    - "proxy.golang.org"

See Network Configuration for more information.

Generated by Repo Assist · 182.1 AIC · ⊞ 10.8K · ◷
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55