Repository navigation
ci: name the attribution caller distinguishably - #1
Conversation
A pull request's Actions list showed two identical "Attribution" entries: this thin caller and the organization ruleset's own run from shared-ci. Both are by design, so the caller is renamed "Attribution (strip + check)". The file is byte-identical to the canonical caller. The required check is keyed on the job, attribution / No AI attribution, and is unaffected.
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_54f409de-dbb3-4e9a-982a-38cc7087634e) |
|
Bugbot could not run here (usage limit), so this is the findings review in its place. Scope: one file, The one thing a workflow rename can break is a required status check that is keyed on the workflow name. It is not: the org ruleset requires the context Drift: the file is byte-identical to the org template (blob No findings. |
A pull request's Actions list shows two identical "Attribution" entries: this repository's thin caller, which strips with write permission, and the organization ruleset's own run from
shared-ci, which enforces read-only and survives a repository deleting its caller. Both are by design, so the caller is renamed to tell them apart.Change
.github/workflows/attribution.yml: the workflow is named "Attribution (strip + check)", with a four-line comment saying why. Nothing else changes. The file is byte-identical to the canonical caller every Wilkes & Liberty repository carries.Why it cannot break enforcement
The required status check is
attribution / No AI attribution. That name comes from the job, not the workflow, so it is unchanged. This pull request's own checks show it.No module or package code changes, so there is no changelog entry.