Add GitHub Actions workflow for auto-labeling issues

[jashansinghTT]

What

Adopt the org's current community-labeling caller, repo-community-labeling.yml, byte-identical to the template in tenstorrent/.github, and delete the superseded community-issue-tagging.yml that #79 merged.

Why

The two files fire on the same triggers (issues: opened, pull_request: opened), so keeping both would run two labeling jobs per issue/PR. The one being deleted is dead: its callee never declares the token it reads, so the membership check 401s and its label step is commented out upstream. On main today every PR shows it as startup_failure (e.g. run 34990861263). The new callee, issues-community-autotag.yml, declares AUTOLABEL_COMMUNITY_ISSUES as a required secret and really applies the label; tt-flash and tt-kmd have already made the same swap.

Prerequisite (not visible in the diff)

AUTOLABEL_COMMUNITY_ISSUES is not yet granted to this repo. The run of this workflow on this branch, 34367798263, failed at Check organization membership with HTTP 401. An org admin needs to add tenstorrent/tt-model-manager to that org secret's repository access list (or add a repo secret of the same name). Until then every run fails at startup.

Related

• fix(community-autotag): apply the community label as github-actions[bot], not the PAT owner tt-github-actions#157 makes the callee apply the label with github.token, so label events show as github-actions[bot] instead of the PAT owner. No change to this caller is needed for that.
• Fork PRs still fail red at the membership step because pull_request from a fork gets no secrets. Upstream issue, deliberately not worked around here so this file stays a clean copy of the template.

🤖 Generated with Claude Code

[ezietlowTT]

The file is right — I'd merge it unchanged. One repo-level thing to settle first, and it isn't about this file's contents.

I checked the template first this time. This is byte-identical to the org template tenstorrent/.github → workflow-templates/repo-community-labeling.yml, and unlike the one in #79 it is the version the org is migrating to: tt-flash and tt-kmd have both replaced the contents of their community-issue-tagging.yml with exactly this caller. The secret handling is correct too — issues-community-autotag.yml declares AUTOLABEL_COMMUNITY_ISSUES under on.workflow_call.secrets as required: true, so passing it explicitly is right, and it is the fix for the gap I flagged on #79.

The one blocker: #79 merged an hour ago, and this duplicates it

b0783d4 landed #79, so main now has .github/workflows/community-issue-tagging.yml. This PR adds a second file on identical triggers:

	merged #79	this PR
file	community-issue-tagging.yml	repo-community-labeling.yml
triggers	issues: [opened], pull_request: [opened]	same
calls	on-community-issue.yml@main	issues-community-autotag.yml@main
does it work	no — see below	yes, for issues and same-repo PRs

Merge this as-is and every new issue and PR fires two community-labeling jobs. The older one is the one I confirmed is dead: tt-studio run 34095486994 and tt-forge run 33954443282 both log HTTP Status: 401 → Detected community member for Tenstorrent employees, and its labelling step is commented out upstream anyway. So we'd be keeping a broken no-op alongside its working replacement.

The ask is one line: delete .github/workflows/community-issue-tagging.yml in this PR. That is what tt-flash and tt-kmd effectively did. Please don't change the new file — it should stay byte-identical to the template.

If the coexistence is deliberate — tt-studio does currently carry both, so it's not unprecedented — say so and I'll approve immediately. I'd just rather not have it happen by accident.

Two things to know, neither blocking and neither yours

Fork PRs fail red. Production-confirmed: tt-flash PR #113 came from a fork (alayander/tt-flash) and run 33434088122 failed at Check organization membership, because pull_request from a fork gets no secrets. Same-repo PRs (tt-kmd run 34284526036) and issues events both pass. So the pull_request trigger reliably produces a red X on exactly the contributions it exists to label — and the summary step then prints ✅ No action needed - user is an organization member about that external contributor, because the empty output falls through the "" = "false" check. Worth taking to whoever owns issues-community-autotag.yml; pull_request_target is the usual answer. Please don't work around it here by diverging from the template.

AUTOLABEL_COMMUNITY_ISSUES must actually be granted to this repo. It's required: true, so if the org secret isn't scoped here every run fails at startup. Presumably already handled if you rolled it out elsewhere — just flagging it as the one prerequisite.

Nothing else. The template carries a trailing space on contents: read and a whitespace-only line, which I'd leave alone precisely because it's the template.

[ezietlowTT]

@jashansinghTT I've made the change I asked for directly on this branch so it isn't blocked on you — please review, since it's your PR and I shouldn't be the only pair of eyes on my own edit.

What I changed

One commit, 7943878, rebased onto current main:

• deleted .github/workflows/community-issue-tagging.yml (the one Add community issue and PR labeling workflow #79 merged)
• left repo-community-labeling.yml completely untouched — still byte-identical to the org template at tenstorrent/.github, verified by diff after the rebase, so it keeps inheriting upstream fixes

Net diff is -12 / +18.

Why the deletion, verified rather than asserted

Both files fire on issues: [opened] and pull_request: [opened], so with both present every new issue and PR runs two community-labelling jobs. The one I removed is the dead one, and I re-checked that today rather than trusting my earlier read:

• on-community-issue.yml's "Add community label" step is still commented out (line 55, unchanged upstream since 2025-08-18), so it only prints debug output.
• It reads secrets.TT_BOT_ORG_MEMBERS_READ_TOKEN without declaring it under workflow_call.secrets, and the caller passes no secrets and doesn't use secrets: inherit — so the token arrives empty, the membership curl 401s, and every author is classified a community member. In production: tt-studio run 34095486994 and tt-forge run 33954443282 both log HTTP Status: 401 → Detected community member for Tenstorrent employees.

Your issues-community-autotag.yml is the live one: it declares AUTOLABEL_COMMUNITY_ISSUES as a required workflow_call secret, this caller passes exactly that, and it really applies the label (gh issue edit --add-label). It's also where the org is heading — tt-flash and tt-kmd have both swapped the contents of their community-issue-tagging.yml for this same caller.

How I tested it

No hardware or app path here, so I tested the thing that actually breaks in reusable workflows — the caller/callee contract. Five checks, run against both pairs:

check	new pair (this PR)	pair being deleted
every required secret is passed	PASS	PASS
nothing passed that the callee doesn't declare	PASS	PASS
no required inputs omitted	PASS	PASS
caller permissions ≥ callee job's	PASS	FAIL — needs issues: write, pull-requests: write; caller grants neither
no secret used by the callee but never declared+passed	PASS	FAIL — TT_BOT_ORG_MEMBERS_READ_TOKEN

That last check is the #79 failure mode expressed mechanically, and I deliberately confirmed it fails on the old pair before trusting it on the new one — a check that only ever passes proves nothing. Also confirmed the YAML parses and only one workflow now claims those triggers.

One prerequisite that is not visible from the diff

AUTOLABEL_COMMUNITY_ISSUES is declared required: true, so it must actually be granted to this repo (org secret scoped here, or a repo secret) or every run fails at startup. I can't read secret names with my token, so please confirm — you'd know from the other rollouts.

Still true, still upstream, still not blocking

Fork PRs fail red: pull_request from a fork gets no secrets, so the membership step errors and the job goes red on exactly the contributions this exists to label — tt-flash PR #113 (fork) failed at Check organization membership, while same-repo PRs and issues events pass. pull_request_target is the usual fix and belongs in tt-github-actions, not here. I've deliberately not worked around it locally, so this file stays a clean copy of the template.

I'll leave my changes-requested in place for you to dismiss if you're happy with it, rather than clearing my own block.

[ezietlowTT]

Re-reviewed after the update — my one blocker is resolved. Approving.

794387894 deletes the superseded community-issue-tagging.yml, so this is now a clean swap: the dead 401 no-op is gone and only the working issues-community-autotag.yml caller remains. That's exactly what tt-flash/tt-kmd did, and it removes the double-labeling I flagged.

Confirmed the new repo-community-labeling.yml is still byte-identical to the org template in tenstorrent/.github (trailing whitespace and all — correctly left alone), and Cycode is green.

Merge whenever ready. The only remaining item is the repo-settings prerequisite from my first review, not this file: AUTOLABEL_COMMUNITY_ISSUES is required: true and isn't scoped to this repo yet (the sole run on this branch is still the startup 401 at Check organization membership). An org admin needs to grant that secret to tenstorrent/tt-model-manager or every run fails at startup. Fork PRs will also still show a red X at the membership step — upstream behavior, correctly not worked around here.