[GHA] Add workflow to assign per-company triage labels to PRs

[bhouse-nexthop]

Description of PR

Summary:
Adds a GitHub Actions workflow that automatically labels each new pull request with two triage-<company> labels, to spread PR triage load evenly across Arista, Cisco, Microsoft and Nexthop.

Opened as a draft for evaluation — see the open questions at the bottom before this is considered for merge.

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202311
• 202405
• 202411
• 202505
• 202511
• 202512
• 202605

Tracking issue/work item for backport/cherry-pick request: N/A
Failure type: N/A

Approach

What is the motivation for this PR?

PR triage currently has no systematic assignment. This distributes every incoming PR to two companies, so each PR has a clear set of owners for triage, and the load is spread evenly over time. A PR is never assigned to the company its author works for.

How did you do it?

Three files:

File	Purpose
.github/workflows/assign_triage_labels.yml	Workflow: pull_request_target (opened/reopened), weekly cron, and workflow_dispatch
.github/triage-assign/companies.yml	Config: companies, org names, username suffixes, per-user overrides
.github/triage-assign/assign_triage_labels.py	The assignment logic

No credentials required. Everything the workflow reads is public: the author map below, and the repo's own PRs via the default GITHUB_TOKEN. No repo or org secret needs to be provisioned before this can run.

Even distribution without tracking. The two companies are drawn from a random.Random seeded with sha256("<owner>/<repo>#<pr_number>"). This needs no persistent state, and is idempotent — re-running on the same PR always produces the same two companies, so the backstop scan can never reshuffle an existing assignment.

Author exclusion. The author's own company is removed from the draw. Affiliation is resolved in order:

1. the overrides map in companies.yml, for people the author map has not caught up with, or whose username carries no company suffix
2. sonic-tsc/sii_author_predict.csv — public, fetched anonymously over raw.githubusercontent.com
3. a username suffix heuristic — -arista, -cisco/-csco, -microsoft/-msft, -nexthop

If the fetch fails, the workflow logs a warning and carries on with the suffix heuristic rather than erroring out.

Two properties of that CSV drive the parsing:

• Others means "unknown", not "some company other than these four". 842 of its 1765 rows sit in that bucket, and 31 of those carry a company suffix (aajith-arista, bining-nexthop, balram-csco, tadams-msft, …). Treating a map hit as authoritative is correct for a real org — someone listed as Nvidia should not have a coincidental username ending exclude a company — but applying that to Others would silently drop all 31. Such values are listed under a new unknown_organizations key in companies.yml and filtered out at load, so the suffix heuristic still sees those authors.
• Three authors appear twice with conflicting organizations, one under the placeholder value author_org_dup. The row with the highest Score wins.

Backstop. Besides firing on PR open, the workflow runs weekly and can be triggered manually to scan open PRs carrying no company label yet. This covers PRs opened while the workflow was failing or disabled, and allows labelling historic PRs. Manual runs take a dry_run input to preview assignments without applying them, and a scan_limit input to bound the scan.

How did you verify/test it?

• Author resolution against the live CSV: 921 authors carry a known organization, of which 393 resolve to the four configured companies — Microsoft 137, Cisco 113, Arista 72, Nexthop 71. The other 528 (Nvidia, Broadcom, Google, Marvell, …) correctly exclude nothing. No CSV organization contradicts the suffix heuristic in any row, so the fallback never disagrees with the map. Spot-checked map hits, Others-plus-suffix fallbacks, per-user overrides, non-participating orgs, and unknown authors.
• Distribution, over 40k synthetic PRs with all four companies eligible: 20000 / 20118 / 19907 / 19975 — each within 0.5% of an even share, and all six company pairs within ~2% of even. With a Cisco author excluded across 30k PRs, the remaining three split 20139 / 19923 / 19938.
• Determinism: repeated draws for the same PR number are identical.
• End-to-end, with a mocked GitHub client: both single-PR and scan modes, missing-label creation, skipping already-labelled PRs, and dry_run applying nothing.
• flake8 --max-line-length=120 clean, matching this repo's pre-commit config.

Any platform specific information?

None — CI infrastructure only, no test or testbed code is touched.

Supported testbed topology if it's a new test case?

N/A

Documentation

No wiki update yet. Happy to add one describing what the triage-* labels mean and what the assigned companies are expected to do, if that is wanted.

---

Open questions / required before merge

1. The triage-* labels do not exist in this repository yet. The workflow creates any that are missing on first run (colour c5def5, overridable per-company via label_color), which is why it requests issues: write.

2. Suggested rollout: a manual run with dry_run: true first, to review assignments against real PR authors before anything is labelled.

3. Company list is currently Arista, Cisco, Microsoft, Nexthop. Adding a company is a one-entry change to companies.yml.

4. Which author map to use. sonic-tsc carries two. This uses sii_author_predict.csv; the older sii_author_map/author.csv is not suitable — its organization column is free-form GitHub profile text rather than curated data (cisco, Cisco Inc., cisco systems, MSFT, and one entry reading @Coinbase @Microsoft @Snapchat @linkedin @IBM … that substring matching would misattribute to Microsoft), 582 of its 1520 rows have a null organization, and its coverage of the four companies is far thinner:

   	sii_author_predict.csv (used)	sii_author_map/author.csv
   Arista	72	1
   Cisco	113	61
   Microsoft	137	129
   Nexthop	71	22

   An earlier revision of this PR read contributors.json from sonic-net/sonic-contributor-map instead. Its coverage is somewhat better still (84 / 140 / 153 / 72), but that repository is private: it needs a CONTRIBUTOR_MAP_TOKEN secret and sonic-net admin rights to provision one before the workflow can resolve anyone. The public CSV plus the suffix heuristic closes most of that gap at no operational cost. If the TSC would rather use the private map, switching back is a small change — happy to do it.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.