ci: restore auto-add-to-project as reusable workflow

[lml2468]

Summary

Restore auto-add-to-project.yml as an org-level reusable workflow, consistent with the existing reusable pattern used by issue-welcome, octo-issue-feed, octo-pr-feed, etc.

Changes

• Re-adds .github/workflows/auto-add-to-project.yml
• Supports both workflow_call (called by per-repo callers) and direct trigger for the .github repo itself
• Uses actions/add-to-project@v1.0.2 (pinned commit hash)

Next

Per-repo caller workflows for all 8 sub-repos will be added in separate PRs after this is merged.

[yujiawei]

Code Review — PR #12 (.github)

Summary

Restores auto-add-to-project.yml as a reusable workflow, just one day after PR #11 removed the same file. The restored YAML is technically sound: dual triggers (workflow_call + direct issues/pull_request_target) are consistent with how this file was structured in PR #4, the action is SHA-pinned to a verified v1.0.2 tag, and permissions: {} correctly minimises the default GITHUB_TOKEN scope.

The main concern is process / decision rationale, not the YAML itself.

1. Verification

Item	Status	Evidence
SHA pinning matches v1.0.2	✅	actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e — verified against the upstream tag ref
permissions: {} empties default GITHUB_TOKEN	✅	Line 27
Reusable-workflow shape consistent with siblings	✅	Mirrors pr-merged-done.yml (also workflow_call + secrets.PROJECT_TOKEN + permissions: {})
Reverts the change in PR #11	⚠️	Confirmed via git log — file was deleted 1 day ago in d5ab928
pull_request_target does not check out PR code	✅	No actions/checkout step; only add-to-project is invoked, which does not run untrusted code
timeout-minutes set on the job	❌	Missing — see §2.2
PROJECT_TOKEN documented as a hard dependency for the .github repo's own issues/PRs	❌	Not mentioned in the file header or PR body

2. Findings

2.1 P1 — Reversal of PR #11 lacks rationale (process)

PR #11 (d5ab928, merged ~12 hours before this PR was opened) removed this exact workflow with an explicit, documented rationale:

Replace with GitHub org Projects native Auto-add workflow rule […]

• Zero Actions minutes consumed
• No PROJECT_TOKEN dependency
• Covers all org repos via a single project settings config
• Lower maintenance overhead

This PR's body says "Restore … consistent with the existing reusable pattern" but never addresses why the four bullets above no longer hold. Reviewers and future maintainers will hit this same question. Concretely:

• Is the org-level native auto-add rule failing for some event type (PRs from forks, draft PRs, transferred issues)?
• Did it not respect a project view filter you needed?
• Is this restoration only intended for a subset of repos that the native rule cannot cover?

Recommendation: add 2–3 sentences to the PR body (and ideally a comment near the top of the file) explaining the trigger for the reversal, so the next person reading git log does not have to re-derive the trade-off. Without this context the change looks like churn and the next maintainer is likely to remove it again.

2.2 P2 — Missing timeout-minutes (consistency)

Sibling reusable workflows in this repo set a job-level timeout, e.g. pr-merged-done.yml uses timeout-minutes: 10, and PR #6 explicitly hardened the notify workflows by setting timeout-minutes: 3. The new file does not set one and will fall back to GitHub's 360-minute default. While actions/add-to-project is fast, a transient hang on the GraphQL call could otherwise burn minutes on every issue/PR opened.

jobs:
  add-to-project:
    runs-on: ubuntu-latest
    timeout-minutes: 5    # add this

2.3 P2 — PROJECT_TOKEN dependency for direct triggers is undocumented

For the workflow_call path the secret is declared (secrets.PROJECT_TOKEN, required). For the direct issues: and pull_request_target: paths in this repo, the same name secrets.PROJECT_TOKEN is read — but now it must exist as a secret on the .github repository (or as an org-level secret made available to it). If it does not, the workflow fails silently from the perspective of anyone opening an issue here.

The header comment lists the caller-side example but does not mention the local-repo prerequisite. Suggest adding one line:

# Direct triggers in this repo also require the PROJECT_TOKEN secret to be
# configured on Mininglamp-OSS/.github (or as an org-level secret).

2.4 P2 — pull_request_target is safe here, but worth a defensive comment

pull_request_target runs in the context of the base repo with full secret access on PRs from forks. The reason this is safe in this workflow is that no PR code is ever checked out or executed — only the upstream actions/add-to-project is invoked, with PROJECT_TOKEN and a static project URL. A future contributor who adds an actions/checkout step here (e.g. to enrich the project item with PR metadata from the PR's own files) would silently re-introduce the classic pwn-request vector.

Suggest a short pinned comment so the constraint is visible at the point of edit:

# pull_request_target is used so we can write to the org project from forks.
# DO NOT add `actions/checkout` of the PR ref here — would expose PROJECT_TOKEN
# to untrusted code.

2.5 Nit — Reusable workflow naming inconsistency

Sibling reusable workflows include the suffix (Reusable) / (reusable) in name::

• name: Issue Welcome (Reusable)
• name: Octo CI Status (reusable)
• name: Octo Issue Feed (reusable)
• name: Octo PR Feed (reusable)

This file uses name: Auto add to project. Minor, but the prior version was also unsuffixed, and fixing it now keeps the Actions UI listing readable.

3. Recommendations

In priority order:

1. (P1) Add rationale to the PR body explaining why the native org-level Auto-add rule introduced in PR #11 is being supplemented/replaced by this Actions-based path.
2. (P2) Add timeout-minutes: 5 to the add-to-project job to match the hardening pattern used elsewhere in this repo.
3. (P2) Document the PROJECT_TOKEN requirement for direct triggers in the file header.
4. (P2) Add an inline warning about not introducing actions/checkout under pull_request_target.
5. (Nit) Rename name: to Auto add to project (reusable) for consistency with the other reusable workflows.

4. Additional observations

• The PR description says "Per-repo caller workflows for all 8 sub-repos will be added in separate PRs after this is merged." Until those land, this PR has no observable behavioural effect on any repo other than .github itself. That's fine for scope, but worth flagging in the PR body so reviewers don't expect immediate org-wide effect after merge.
• Consider whether the org-level native auto-add rule (mentioned in PR #11) should be disabled once the reusable workflow path is live across the 8 sub-repos. Otherwise both paths will run in parallel; actions/add-to-project is idempotent (adding an already-present item is a no-op), so this is not a correctness bug, but it doubles the latency to "appear on the board" perception, and burns Actions minutes that PR #11 was deliberately trying to save.

[lml2468]

All review feedback addressed in the latest commit:

• P1: Added rationale in file header — native Auto-add rule requires UI-only config, violates IaC, hence the Actions-based approach
• P2: Added timeout-minutes: 5 to job
• P2: Documented PROJECT_TOKEN requirement for direct triggers in the header
• P2: Added inline security warning against actions/checkout under pull_request_target
• Nit: Renamed to Auto add to project (reusable)

[yujiawei]

Code Review — PR #12 (.github)

Summary

All five concerns from the prior review on d2419134 have been addressed in head 3c0e4be. The restored reusable workflow is technically sound, follows the same shape as sibling reusable workflows in this repo, and pins actions/add-to-project to a verified commit hash.

1. Verification of prior-review fixes

Item	Status	Evidence
P1 — Rationale for reverting PR #11	✅	Lines 8–14: explicit "Why a workflow instead of GitHub's native Auto-add rule" block citing IaC (no API for the UI rule, can't be reviewed / version-controlled / reproduced)
P2 — timeout-minutes set	✅	Line 53: timeout-minutes: 5 on the add-to-project job
P2 — PROJECT_TOKEN requirement for direct triggers documented	✅	Lines 16–20: explicit "Direct-trigger requirements" paragraph noting the secret must be configured on .github (or org-level)
P2 — Defensive comment on pull_request_target + actions/checkout	✅	Lines 38–44: "SECURITY: do NOT add actions/checkout … checking out untrusted PR code here would let a malicious fork exfiltrate the token"
Nit — Reusable suffix in name:	✅	Line 28: name: Auto add to project (reusable), consistent with Octo Issue Feed (reusable), Octo PR Feed (reusable), etc.

2. Independent verification

Item	Status	Evidence
actions/add-to-project SHA pin matches v1.0.2	✅	244f685bbc3b7adfa8466e08b698b5577571133e matches refs/tags/v1.0.2 on actions/add-to-project (verified via GitHub API)
permissions: {} correctly empties the default GITHUB_TOKEN scope	✅	Line 47; the action uses the explicit PROJECT_TOKEN PAT instead, so no default-token permissions are required
pull_request_target is safe in this workflow	✅	No checkout step, no PR-supplied script paths, only the upstream action runs against a static project-url and the secret token
Trigger surface is correct	✅	workflow_call for the org-fan-out path; issues: [opened] and pull_request_target: [opened] for the .github repo's own items. Adding to a project is idempotent, so [opened]-only is sufficient
Single-file diff, additive only	✅	+58 / -0, no other files touched

3. Findings

No blocking issues. One minor observation, not blocking:

3.1 Nit — project-url is hard-coded, not an input

The reusable workflow always writes to https://github.com/orgs/Mininglamp-OSS/projects/2. That matches the stated design intent ("a single, centrally maintained automation"), so this is fine for the immediate goal. If a future sub-repo ever needs to land in a different project (e.g. a private security project, or a per-team board), this will require either a workflow edit or a fork. Worth keeping in mind, not worth changing now.

3.2 Observation — Coexistence with the native Auto-add rule

The previous PR (#11) introduced the org-level native Auto-add rule and removed this workflow. This PR restores the workflow but does not say whether the native rule is also being kept. If both run in parallel after the 8 caller workflows land, actions/add-to-project is idempotent so there's no correctness bug, but Actions minutes are spent on what the native rule would have done for free. Worth deciding (and noting in the rollout plan) whether the native rule will be disabled once the reusable-workflow path is wired up across sub-repos. This is a process / rollout note, not a change request on this PR.

4. Recommendation

Approve. The YAML is correct, the security-sensitive pull_request_target path is properly contained, the SHA pin is verified, and every prior-review concern is resolved with documentation that survives in the source rather than only in the PR thread.