Author format commits as the App's own bot user

[anandhu-eng]

Problem

format.yml pushes with the mlc-automations GitHub App token, but hardcoded a user account as the commit author:

git config --global user.name mlc-automations
git config --global user.email "3246381+mlc-automations@users.noreply.github.com"

GitHub resolves <id>+<name>@users.noreply.github.com by the numeric id and ignores the name entirely. Id 3246381 is not the App — the App's bot user is id 272923709:

$ gh api /users/mlc-automations%5Bbot%5D --jq '{login,id,type}'
{"login":"mlc-automations[bot]","id":272923709,"type":"Bot"}

So every [Automated Commit] Format Codebase commit has been credited to account 3246381, a separate user account. That account is now named bumper97birch, and github.com/bumper97birch, GET /users/bumper97birch and the GraphQL node lookup all return 404 / NOT_FOUND.

cla-bot resolves those commits to an unsigned contributor and fails the check on any PR the format bot has committed to. The display name still reads mlc-automations because that string is baked into the commit, which is what made this confusing to diagnose.

Effect today

Three open PRs are blocked: #285, #274, #265.

This passed until recently because the CLA allowlist named mlc-automations and account 3246381 carried that login. The same defect and the same fix apply to mlcommons/mlperf-automations (mlcommons/mlperf-automations#1104), where the rename was first noticed.

Changes

1. format.yml — resolve the App's bot user id at run time from steps.app-token.outputs.app-slug, per the create-github-app-token README, rather than hardcoding a number that can silently go stale.
2. cla.yml — allowlist mlc-automations[bot] instead of mlc-automations. Note bot* is a prefix glob and does not cover ...[bot], so the explicit entry is required. Dropping the stale entry matters independently: mlc-automations is currently an unclaimed GitHub username, so anyone who registered it would have been auto-allowlisted on this repo.
3. format.yml skip guard — github.actor != 'mlc-automations' never matched, because an App-token push sets the actor to mlc-automations[bot]. The workflow has been re-triggering on its own format commits (visible on a8e187953, actor mlc-automations[bot]). Harmless, as autopep8 is idempotent, but it burned a run each time.

No history rewrite needed

The 18 commits already on main are untouched. cla-bot/src/graphql.ts queries pullRequest.commits, i.e. only commits reachable from the head branch and not the base — so merged history is never re-inspected. Confirmed empirically in mlperf-automations, where every PR merged since the rename passed CLA cleanly.

Rewriting main would also invalidate every fork, clone, open PR base and recorded release-provenance hash, for no benefit.

Once this lands, the three branches above need a rebase; the bot will recreate the format commits with the correct identity.

Open question

Whether account 3246381 was ever under the MLCommons organization, and what it was originally intended to be, is not answerable from outside — the account is not resolvable through any public endpoint. The org audit log or GitHub Support can confirm. It does not block this fix.

---

🧾 PR Checklist

• No unintended files committed
• Inline comments explain the non-obvious part (why the id is looked up rather than written down)
• PR title and description state what and why
• No secrets or credentials committed
• YAML validated; the resolve step was run locally and produces 272923709+mlc-automations[bot]@users.noreply.github.com

🤖 Generated with Claude Code

[github-actions]

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

[github-actions]

🤖 AI PR Review Summary

This PR updates GitHub Actions workflows to correctly handle bot usernames with '[bot]' suffixes in allowlists and conditional checks, and dynamically resolves the bot's GitHub user ID and email for git commits. The main risk is ensuring the dynamic resolution of bot identity works reliably and that the syntax for referencing outputs in git config commands is correct. The change improves maintainability by avoiding hardcoded IDs but requires validation of the new dynamic approach.