1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig

[dblanken-yale]

1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig

Description of work

• Adds .github/workflows/project_status_sync.yml, which keeps this repo's PRs and the YaleSites Board in step so nobody has to move cards by hand:
  • needs review label added → linked ticket goes to In review
  • merged to develop → Ready for Release (in dev)
  • merged to main/master → Done
• All the logic lives once, in yalesites-org/.github, and is called as a reusable workflow. This file is 12 lines of configuration and nothing else, so the three repos cannot drift apart. Full documentation: docs/project-status-sync.md.
• The if: guard skips PRs from forks, where secrets are unavailable and the job could not do anything.

Merge order: yalesites-org/.github must merge first. This workflow references yalesites-org/.github/.github/workflows/project-status-sync.yml@main, which 404s until the shared half lands on main.

This ships dormant until an admin creates the token. PROJECT_TOKEN (a PAT with repo + project + read:org) needs to be an org-level secret shared with this repo; Project v2 fields cannot be written with the default GITHUB_TOKEN. Until it exists, the workflow logs a warning and exits 0 — deliberately, so this cannot put a red X on every merge.

The ticket matching is by convention: the branch name (1234-description), the PR title (1234: Title), or the body's References yalesites-org/YaleSites-Internal#1234 line. GitHub's own closingIssuesReferences is not used, because References is deliberately not a closing keyword and so GitHub never records the link. A PR that matches nothing — a dependency bump, an RC update — is logged and skipped, never failed.

Functional testing steps:

• Confirm this file is identical to the copy in the other two code repos (it is a straight copy, so any difference is a mistake).
• Confirm the review logic itself in the yalesites-org/.github PR — that is where the behavior lives.

After the org secret PROJECT_TOKEN is created and shared with this repo:

• Open a throwaway PR from a branch named 1385-something, add the needs review label, and confirm ticket 1385 moves to In review on the board.
• Merge a ticketed PR to develop and confirm its ticket moves to Ready for Release (in dev).
• Merge a PR with no linked ticket and confirm the run is green with a warning, not a failure.

References yalesites-org/YaleSites-Internal#1385

Other work completed in

This is one work-unit across four repos, all on branch 1385-project-status-sync:

• 1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig .github#2 — the shared reusable workflow, its logic, its tests, and the documentation. Must merge first; the other three reference it at @main.
• 1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig #505 — caller workflow
• 1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig component-library-twig#695 — caller workflow
• 1385: Automate GitHub Project Status updates on PR merge across yalesites-project, atomic, and component-library-twig yalesites-project#1476 — caller workflow

Scoping and Done semantics (updated in yalesites-org/.github 12016ef)

Two corrections landed in the shared workflow after review; they change behavior for this repo, so they are worth knowing while reviewing:

• Only the YaleSites repos may use the shared workflow. It lives in a public repo, so GitHub would otherwise let any repository call it. There is now an explicit allow list (yalesites-project, atomic, component-library-twig, tokens, YaleSites-Internal), and the org secret must be scoped to selected repositories rather than all of them.
• Only yalesites-project marks a ticket Done. In atomic and component-library-twig, a merge to main is the RC promotion — an intermediate release step, not "shipped" — so tickets carried by an RC Update stay at Ready for Release (in dev). This matches what the board already records for the 2026-08-14 component-library-twig RC (1529, 1532, 1536, 1537).

Update: Done is now decided by a board sweep (yalesites-org/.github 256f778)

Behavior change worth knowing while reviewing. Measured against the real v2.23.0 release, the original design would have marked only 9 of the 12 tickets that release shipped as Done — three (1239, 1266, 1311) were companion-only and would have been stranded at Ready for Release (in dev) forever.

Now, when yalesites-project merges to master, the workflow sweeps every ticket at Ready for Release (in dev) and marks it Done once all of its merged PRs — across yalesites-project, atomic, component-library-twig, and tokens — have reached their repo's production branch. A ticket that is not already at Ready for Release (in dev) is never touched, so work landing on a ticket that is deliberately held open for more work cannot complete it early.

Nothing changes in this file; the caller is unchanged.

[dblanken-yale]

Closing for now; I think we are going to try a different method, but will keep this branch here in case we need it.