[ASM] [CI] Remove committed scratch files and stop two from coming back

[Boss2002n]

Six tracked files that nothing reads and nothing will read again.

CI scratch committed by the bot. update-split-tests.yaml writes split-tests-update-summary.md and then pr-body.md into the workspace and hands them to peter-evans/create-pull-request, which has no add-paths filter and so commits every dirty file it finds. Both landed in the repo root that way in #5131. The workflow regenerates them on every run, so the tracked copies are stale by definition; .gitignore now keeps the bot from re-adding them.

Merge and POC leftovers that ship in the wheel.
hsa/gfx950/pa/pa_bf16_noquant_gqa8_1tg_4w.co.orig and .co.poc_kl_merg arrived with #3211 next to the real .co. Nothing references either by name, and the ASM loaders build .co paths explicitly rather than globbing the directory, so neither is reachable. They are not merely inert: setup.py copies all of hsa/ into aiter_meta and MANIFEST.in grafts it, so 48 KB of scratch binaries go out in every wheel. *.orig is now ignored so the next conflicted merge does not leave another one behind.

One-off files their PRs forgot. probe_noqa_check.py is a single line, x = 1, added in #4403 to confirm the pinned ruff config flagged it. REPO_CLEANUP_PLAN.md is a pull request description from #2167 in March. Its Phase 1 shipped -- the .pt test data is gone from main and the size rules are in .gitignore -- and its Phase 2 history rewrite needs a coordinated force push that has not happened in the six months since. Neither file is referenced anywhere in the tree.

[github-actions]

🏷️ CI Guide

Runs automatically on every PR:

• ✅ Pre-checks (submodule verification, code formatting)
• ✅ Aiter op tests (gfx942 + gfx950)
• ✅ Triton tests on MI35X (only when aiter/ops/triton/** or related paths are changed)

Extended tests (opt-in via labels):

Label	Tests
ci:gfx1250-ffm-triton	Run the five-shard gfx1250 FFM Triton test suite
ci:triton-300x	Run an additional Triton test job on MI300X in PRs; main branch always runs both MI35X and MI300X
multigpu	Aiter multi-GPU tests on the 8-GPU runner
ci:sglang	SGLang integration tests: DeepSeek-R1-MXFP4 accuracy, Qwen 3.5 accuracy
ci:atom	ATOM benchmark: DeepSeek-R1-0528, GPT-OSS-120B
ci:atom_full	ATOM accuracy suite for PR and main models from ATOM models_accuracy.json
ci:vllm	vLLM benchmark: GPT-OSS-120B, DeepSeek-R1-0528, Kimi-K2.5
ci:all	All standard extended tests (excludes ci:atom_full)

Only add ci:atom_full for FlyDSL or Triton upgrades.
Add labels via the sidebar or gh pr edit 5544 --add-label <label>

PR title tags & labels:
Component tags ([Triton/Gluon], [HIP], [CK], [ASM], ...) are added to the PR title and as PR labels automatically from the changed files and re-synced on every push — change-type tags like [fix]/[Perf], op tags like [MLA], and human labels (ci:*) are left untouched. Add the no-auto-title label to opt this PR out.

[Copilot]

🟢 Approval recommended

The only noted issue is a non-blocking documentation nit.

Pull request overview

Removes stale CI artifacts and unreferenced scratch files while preventing them from being recommitted.

Changes:

• Deletes obsolete generated files, documentation, probe code, and binaries.
• Adds .gitignore rules for CI outputs and merge backups.

File summaries

File	Summary
split-tests-update-summary.md	Removes stale CI output.
REPO_CLEANUP_PLAN.md	Removes obsolete cleanup documentation.
probe_noqa_check.py	Removes one-off lint probe.
pr-body.md	Removes generated PR body.
.gitignore	Adds ignore rules; nit: update the inaccurate add-paths comment or configure the workflow input.

Review details

• Files reviewed: 4/7 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

No unresolved review issues were identified.

Review details

• Files reviewed: 5/8 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

No unresolved blocking issues were identified.

Review details

• Files reviewed: 5/8 changed files
• Comments generated: 0 new
• Review effort level: Lite

[zufayu]

ROCm/aiter PR #5544 — [ASM] [CI] Remove committed scratch files and stop two from coming back

Deletes six unreferenced scratch files (two CI-generated markdown at the repo root, two leftover gfx950 code objects, a one-line ruff probe, a stale cleanup plan) and stops the CI bot from recommitting its scratch by redirecting workflow output to the runner temp dir and constraining what the bot may commit to split_tests.sh.

Review (advisory): ✅ NO FINDINGS
Validation (deterministic): NOT RUN — triage found no test target ("the PR changes runtime code but ships no test target"); the changed paths are deletions of files nothing loads at run time (neither hsa binary is in hsa/gfx950/pa/pa_asm.csv, the sole co-name source for asm_pa.cu, and nothing references probe_noqa_check.py), so this is the not-executed-at-run-time case — no test target could have covered it and the absence is not a defect
Perf (advisory): NOT RUN — no benchmark entry point (triage: no perf target for the same reason there is no test target); the deleted files sit outside the serving path, so there is no latency a harness could measure

[Copilot]

Copilot review overview

🟢 Approval recommended

Reviewed changes are limited to stale artifacts and safeguards preventing their recreation.

Review effort: Lite
Findings: None

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved blocking issues were identified.

Review effort: Lite
Findings: None

[gyohuangxin]

Thanks for the improvement. But could you explain the reason to delete REPO_CLEANUP_PLAN.md ?

@zufayu can you also check the deletion of probe_noqa_check.py and has/gfx950/pa/*** ?

[Boss2002n]

Thanks for the improvement. But could you explain the reason to delete REPO_CLEANUP_PLAN.md ?

@zufayu can you also check the deletion of probe_noqa_check.py and has/gfx950/pa/*** ?

Its a PR description file - that PR has been merged - rendering this md file moot

[zufayu]

let me check We generally need to be very careful when deleting files.

[zufayu]

Thanks for the clarification. I checked the remaining deletions:

• probe_noqa_check.py is an unreferenced one-line Ruff test artifact.
• The .orig and .poc_kl_merg files under hsa/gfx950/pa/ are unreferenced leftovers; the actual .co used by pa_asm.csv remains.

Those deletions look safe.

REPO_CLEANUP_PLAN.md, however, describes a separate Phase 2 history rewrite that #2167 did not execute. I’m fine with removing it from the repository root, but please first move any still-relevant plan to a tracking issue and link it here—or confirm that the work has been completed or abandoned. After that, this looks good to merge.

[Boss2002n]

Thanks for the clarification. I checked the remaining deletions:

• probe_noqa_check.py is an unreferenced one-line Ruff test artifact.
• The .orig and .poc_kl_merg files under hsa/gfx950/pa/ are unreferenced leftovers; the actual .co used by pa_asm.csv remains.

Those deletions look safe.

REPO_CLEANUP_PLAN.md, however, describes a separate Phase 2 history rewrite that #2167 did not execute. I’m fine with removing it from the repository root, but please first move any still-relevant plan to a tracking issue and link it here—or confirm that the work has been completed or abandoned. After that, this looks good to merge.

Repo size: Phase 2 of REPO_CLEANUP_PLAN.md, retargeted

Phase 1 (from #2167) shipped and is live. Phase 2 never ran — but measuring it first shows the plan aims at the wrong target.

Phase 1: done, in place on main

  |   -- | -- .gitignore lines 65–78 | *.pt, *.pth, *.ckpt, op_tests/test_jenga_vsa/, op_tests/dump_data/, OUT_FOLDER/, *.att .githooks/pre-commit, .githooks/install | present scripts/download_test_data.sh | present

 

A default git clone fetches every refs/heads/* but no refs/pull/*, so a blob reachable only from a deleted branch stops being downloaded the moment that branch is gone — no server-side GC needed for the clone-size win, and no force-push, no coordinated re-clone.

#<stale-branch-archive-PR> ("Archive stale branches instead of deleting them") is exactly this: archive at 30 days, notice at +30, delete the archive ref at +14, skipping protected branches, open-PR refs and a checked-in exemption list.

 

How to reproduce

 

bash

 

Shell

git clone --mirror https://github.com/ROCm/aiter.git m && du -sh mgit -C m rev-list --objects --all \  | git -C m cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \  | awk '$1=="blob" && $3>5000000 {printf "%6.1f MB  %s\n", $3/1048576, $4}' | sort -rn | head -15git -C m log --oneline main -- op_tests/dump_data/q.pt      # empty: not reachable from maingit clone --bare --single-branch --branch main https://github.com/ROCm/aiter.git s && du -sh s

 

Note: a --filter=blob:none clone reports these paths as absent from history. It is wrong; use a full mirror for this measurement

[Boss2002n]

So if we ever want to address phase 2 of this plan then we can use the changes I've made in #5540 and #5617

[zufayu]

Thanks, this answers my question. Phase 1 is complete, and the original Phase 2 history rewrite was never run and is no longer the plan.

Please link the branch-archive tracking issue or PR once it is created, so that follow-up is not lost when REPO_CLEANUP_PLAN.md is removed. Other than that, the deletions look good to me.

[Boss2002n]

Thanks, this answers my question. Phase 1 is complete, and the original Phase 2 history rewrite was never run and is no longer the plan.

Please link the branch-archive tracking issue or PR once it is created, so that follow-up is not lost when REPO_CLEANUP_PLAN.md is removed. Other than that, the deletions look good to me.

Done

[rahulbatra85]

@Boss2002n Is this just a cleanup PR?

[Boss2002n]

@Boss2002n Is this just a cleanup PR?

yes

[brunomazzottiamd]

@Boss2002n, I think we have the green light to merge from CI team, given all the PR discussions. Am I right?

@gyohuangxin / @zufayu can you please get back to this PR and double check if all discussions are addressed according to your requests? Thanks!

[leo-automation]

LGTM