feat: mutation-weekly workflow_dispatch 入口

[randypanding]

加 workflow_dispatch 触发器以支持手动首跑（AI_Web_School）。Cards: Cloudbird-Software/.github#322

Summary by CodeRabbit

• 新功能
  • 支持手动触发每周变更检测工作流。
  • 可选择指定目标仓库，未指定时使用默认仓库。

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: b10458f2-199d-4760-8922-6b0e187fe2a2

📥 Commits

Reviewing files that changed from the base of the PR and between 584281c and d3759e8.

📒 Files selected for processing (1)

• .github/workflows/mutation-weekly.yml

Included review availability: Your plan provides up to 10 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

本次变更为 mutation-weekly 工作流新增手动触发方式，并添加可选的 target_repo 输入，默认值为 Cloudbird-Software/AI_Web_School。

Changes

Mutation 工作流触发配置

Layer / File(s)	Summary
手动触发与目标仓库输入 .github/workflows/mutation-weekly.yml	工作流新增 workflow_dispatch 触发方式，并提供可选的 target_repo 字符串输入及默认仓库值。

Suggested labels: security, feature

Merge Risk: ⚪ Minimal · up to d3759

This change only adds a manual trigger entry point to the weekly mutation workflow, with no actionable merge-blocking risk remaining after normal checks and review.

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	标题使用了有效的 Conventional Commits 前缀“feat:”，长度为 42 个字符，且准确描述了新增 mutation-weekly 工作流手动触发入口的主要变更。

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch mutation-dispatch

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-code-review]

PR Summary by Qodo

Add workflow_dispatch entrypoint to mutation-weekly for manual first run

✨ Enhancement ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Add workflow_dispatch trigger so mutation scoring can be started manually.
• Introduce a target_repo input with a default for AI_Web_School first-run.
• Keep existing workflow_call and weekly schedule behavior unchanged.

Diagram

graph TD
  A{{"Triggers (cron/call/dispatch)"}} --> B["mutation-weekly.yml"] --> C["Checkout repos"] --> D["Run mutation scoring"] --> E["Append ledger"] --> F[("Artifacts / ledger")]
  subgraph Legend
    direction LR
    _t{{"Trigger"}} ~~~ _p["Job/step"] ~~~ _a[("Stored output")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate manual wrapper workflow (calls workflow_call)

• ➕ Avoids duplicating inputs between workflow_dispatch and workflow_call in the same file
• ➕ Keeps the reusable/scheduled workflow focused and stable
• ➖ Adds an extra workflow file and indirection for a small benefit
• ➖ Slightly harder for users to discover the ‘real’ workflow logic

2. Make target_repo required for workflow_dispatch

• ➕ Forces intentional selection and reduces accidental runs against the default repo
• ➖ Less convenient for the explicit first-run use case (AI_Web_School)

Recommendation: Current approach (adding workflow_dispatch directly to mutation-weekly) is the simplest and most discoverable for a one-off/first-run need, while preserving existing workflow_call/schedule behavior. Consider the wrapper-workflow approach only if you expect more manual-only options to accumulate and want to keep the reusable workflow surface minimal.

Files changed (1) +7 / -0

Other (1) +7 / -0

mutation-weekly.ymlAdd workflow_dispatch trigger with target_repo input +7/-0

Add workflow_dispatch trigger with target_repo input

• Introduces a workflow_dispatch entrypoint so the mutation-weekly workflow can be run manually. Adds a target_repo string input with a default of Cloudbird-Software/AI_Web_School to support a manual first run.

.github/workflows/mutation-weekly.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unrestricted dispatch repo execution 🐞 Bug ⛨ Security

Description

Adding workflow_dispatch exposes target_repo to manual runs, and the workflow then checks out that
repository and executes its test code during mutation scoring, enabling running untrusted repository
code on the runner (and increasing compute/abuse risk). This is a new attack surface compared to
schedule/workflow_call-only triggering and should be constrained or validated for workflow_dispatch
runs.

Code

.github/workflows/mutation-weekly.yml[R11-14]

+        description: "Owner/name of the repository to score"
+        required: false
+        type: string
+        default: "Cloudbird-Software/AI_Web_School"

Relevance

●● Moderate

Recent precedent accepts hardening untrusted execution, but similar repository-input security
restrictions were often rejected.

PR-#92
PR-#58

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new workflow_dispatch input enables user-provided target_repo. The workflow uses that value to
checkout a repository into target/ and then runs mutation scoring, which executes the repo’s test
suite via subprocess (pytest or the built-in minimal runner importing test modules).

.github/workflows/mutation-weekly.yml[8-14]
.github/workflows/mutation-weekly.yml[46-80]
pipeline/testing/mutation/run_mutation.py[284-305]
pipeline/testing/mutation/run_mutation.py[308-335]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`workflow_dispatch` introduces a user-controllable `inputs.target_repo`, and the workflow checks out and runs mutation scoring against that repo. Because mutation scoring runs the target repo’s tests (code execution), this enables manual runners to execute arbitrary code from arbitrary public repos, increasing abuse/cost/security risk.

### Issue Context
This workflow checks out `inputs.target_repo` into `target/` and runs `run_mutation.py` against it.

### Fix Focus Areas
- .github/workflows/mutation-weekly.yml[8-14]

### Suggested fix
Add an early validation step for `workflow_dispatch` (only) that enforces an allowlist, e.g.:
- Hard-code `target_repo` for dispatch (remove the input entirely), OR
- Make it `type: choice` with approved options, OR
- Add a bash step that verifies `inputs.target_repo` matches an allowed pattern (e.g. `^Cloudbird-Software/AI_Web_School$` or `^Cloudbird-Software/`), and `exit 1` with a clear message when it doesn’t.

Example snippet:
```yaml
- name: Validate target_repo (dispatch)
 if: ${{ github.event_name == 'workflow_dispatch' }}
 run: |
   case "${{ inputs.target_repo }}" in
     Cloudbird-Software/AI_Web_School) ;; 
     *) echo "Unsupported target_repo for manual runs"; exit 1;;
   esac
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Dispatch input parity missing 🐞 Bug ⚙ Maintainability

Description

The job logic uses inputs.tier (with a default) but workflow_dispatch does not define a tier input,
making manual runs unable to select breadth tiers and creating an inconsistent interface vs
workflow_call. This can lead to confusion and accidental use of the wrong mutation breadth when
manually triggering the workflow.

Code

.github/workflows/mutation-weekly.yml[R8-10]

+  workflow_dispatch:
+    inputs:
+      target_repo:

Relevance

●●● Strong

Manual input parity is a deterministic interface fix, and no close rejection precedent outweighs the
clear mismatch.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

workflow_dispatch inputs added in this PR do not include tier, while the workflow relies on
inputs.tier for tier behavior and already defines tier for workflow_call.

.github/workflows/mutation-weekly.yml[8-26]
.github/workflows/mutation-weekly.yml[35-72]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`workflow_dispatch` defines only `target_repo`, but the workflow already supports a `tier` input under `workflow_call` and uses `inputs.tier` in job naming and tier-to-glob resolution. Manual runs can’t set the tier, making the API inconsistent.

### Issue Context
The workflow already supports `tier` for reusable calls; manual triggers likely want the same capability.

### Fix Focus Areas
- .github/workflows/mutation-weekly.yml[8-14]

### Suggested fix
Add a `tier` input under `workflow_dispatch.inputs` matching `workflow_call.inputs.tier`.
Optionally use `type: choice` with `critical|standard|broad` to prevent typos.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Web pages:

  🌐 workflow-syntax?use_case=

  🌐 content/actions/reference/workflows-and-actions/contexts.md

  🌐 GitHub Actions: Inputs unified across manual and reusable workflows - GitHub Changelog

  +2 more

Review mode: ⚖️ Balanced

_{ⓘ  1 issues published inline · 2 in summary}

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-code-review]

1. Unrestricted dispatch repo execution 🐞 Bug ⛨ Security

Adding workflow_dispatch exposes target_repo to manual runs, and the workflow then checks out that
repository and executes its test code during mutation scoring, enabling running untrusted repository
code on the runner (and increasing compute/abuse risk). This is a new attack surface compared to
schedule/workflow_call-only triggering and should be constrained or validated for workflow_dispatch
runs.

Agent Prompt

### Issue description
`workflow_dispatch` introduces a user-controllable `inputs.target_repo`, and the workflow checks out and runs mutation scoring against that repo. Because mutation scoring runs the target repo’s tests (code execution), this enables manual runners to execute arbitrary code from arbitrary public repos, increasing abuse/cost/security risk.

### Issue Context
This workflow checks out `inputs.target_repo` into `target/` and runs `run_mutation.py` against it.

### Fix Focus Areas
- .github/workflows/mutation-weekly.yml[8-14]

### Suggested fix
Add an early validation step for `workflow_dispatch` (only) that enforces an allowlist, e.g.:
- Hard-code `target_repo` for dispatch (remove the input entirely), OR
- Make it `type: choice` with approved options, OR
- Add a bash step that verifies `inputs.target_repo` matches an allowed pattern (e.g. `^Cloudbird-Software/AI_Web_School$` or `^Cloudbird-Software/`), and `exit 1` with a clear message when it doesn’t.

Example snippet:
```yaml
- name: Validate target_repo (dispatch)
  if: ${{ github.event_name == 'workflow_dispatch' }}
  run: |
    case "${{ inputs.target_repo }}" in
      Cloudbird-Software/AI_Web_School) ;; 
      *) echo "Unsupported target_repo for manual runs"; exit 1;;
    esac
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools