Triage workflow never reaches repos outside the sync set — puppetsync's own 12 open items are invisible to the Org Triage board

[silug]

Problem

add_new_issue_to_triage_project.yml is a puppetsync-managed template (modules/profile/files/_github/workflows/), rolled out on 2023-04-17 by data/sync/configs/20230417-add-gha-issue-triage-action.yaml. It is therefore only present in repos puppetsync syncs — and puppetsync itself is not one of them, so the repo holding the fleet's coordination backlog is invisible to the Org Triage board.

Scanned all 174 non-archived, non-empty repos in the org on 2026-08-27: 88 have the workflow, 86 do not. Of the 86, 74 are vendored upstream forks that legitimately don't need it. The remaining 12 are SIMP-owned:

Repo	Open human-authored issues / PRs	Worth fixing?
puppetsync	11 / 1	yes — the whole fleet-coordination backlog
simp-core	10 / 0	yes
github-action-build-and-sign-pkg-single-rpm	1 / 0	probably
rubygem-simp-build-helpers	1 / 0	probably
.github-private	1 / 1	judgement call
renovate-config	0 / 1	judgement call
bolt-pulp3, gha-workflows, pull-request-dashboard, simp-team-plugins, simp-tpm12-simulator, simp-tpm2-simulator	0 / 0	low value today

The practical impact is concentrated in puppetsync. Every issue currently tracking cross-repo work — #41, #47, #56, #75, #81, #83, #85, #86, #87, #94, #95 and PR #24 — has never appeared on the triage board. Anyone working the board sees the module fleet's issues but none of the work that coordinates the fleet.

simp-core is the second real case: 10 open issues, of which only 8 are on the board (added by some other path), so simp-core#886 and #912 are missing too.

Note this is not a fork problem: the three forks SIMP actually releases — pupmod-voxpupuli-selinux, pupmod-simp-haveged, rubygem-simp-rspec-puppet-facts — all have the workflow.

Root cause

The dynamic inventory (data/sync/repolists/github-org.yaml) selects by name glob:

  include:
    - 'pupmod-*'
    - 'puppet-*'
    - 'rubygem-*'

puppetsync, simp-core, bolt-pulp3, gha-workflows, renovate-config, pull-request-dashboard, simp-team-plugins, simp-tpm*-simulator, github-action-* and .github-private match none of these, so they are never candidates. (rubygem-simp-build-helpers does match the glob but still lacks the workflow — probably culled by permitted_project_types, or simply never synced since 2023; worth confirming which.)

The 2023 rollout config also restricted itself to permitted_project_types: [rubygem, pupmod, simp_unknown].

This is the same shape as #84 and #85: a workflow that exists once as a template, is copied per-repo, and silently doesn't reach whatever falls outside the sync set. It's the third instance — after the RPM registry fix (#80, which missed 9 non-module repos) and the tag_deploy matrix (#84).

Suggested fix

Smallest useful change first: get the workflow into puppetsync and simp-core. Both already have .github/workflows/, so this can be a direct commit rather than a sync run if that's simpler.

Then decide the general rule, since this will keep recurring:

1. Widen the inventory so infrastructure repos are in scope — either add explicit include entries, or invert to "all non-archived SIMP-owned repos except an exclude list". The simp_unknown project type already exists and looks like the natural home for them.
2. Or treat the triage workflow as org-infrastructure rather than a per-project-type asset, and apply it to every SIMP-owned repo regardless of project type.
3. Or fold it into the workflow_call migration (Consider reusable workflows (workflow_call) instead of copying 13 workflow templates into ~79 repos #85) — this workflow is 12 lines and calls actions/add-to-project@v2, so it's a cheap candidate for a central definition plus a thin shim, and would make the "which repos have it" question answerable in one place.

Prerequisite to check

The workflow authenticates with secrets.AUTO_TRIAGE_TOKEN. If that's a per-repo secret rather than an org-level one, adding the workflow to a new repo isn't sufficient on its own — the secret has to exist there too, and a missing secret fails at runtime rather than at sync time. Worth confirming before rolling it wider.

Also worth knowing

Whoever picks this up should know the board is deliberately curated: Renovate items are removed manually, and items are removed as they reach Done, to keep the board small. So "not on the board" does not by itself mean "was never added" — but for the puppetsync issues above it does, since the workflow has never existed there.

[silug]

Two more changes to this same template have been filed: #97 (stop auto-adding Renovate and [puppetsync] PRs) and #98 (flag outside contributions). If the coverage fix here turns into a sync run, those two may as well ride along.