Downstream Updates Needed workflow

Workflow for checking downstream users of these actions (in the elastic and strawgate orgs) and seeing if their workflows need updates. Post an issue with the repo-by-repo updates required.

TL;DR: we should add an internal-only downstream-updates-needed workflow, but first fix the data model because current downstream inventory strips ref data and cannot reliably determine what needs updates.

Recommendation

Implement .github/workflows/gh-aw-downstream-updates-needed.md (+ trigger) as an internal scheduled report workflow that posts a single issue with repo-by-repo required updates for elastic/* and strawgate/*. In the same change, update downstream inventory logic so refs are preserved (at minimum workflow_path, uses_target, ref), otherwise update detection will remain heuristic and noisy.

Findings

There is currently no workflow in this repo that does "downstream updates needed" checks.
- rg "gh-aw-downstream-updates|downstream updates needed" .github/workflows produced no matches.
Existing downstream workflows solve adjacent but different problems:
- .github/workflows/gh-aw-downstream-health.md:81-109 monitors bot quality/errors, not version drift, and discovery text is scoped to elastic-owned repos (:87-95).
- .github/workflows/gh-aw-downstream-users.md:76-114 tracks users, but explicitly strips ref info (:110 removes version suffix).
Current inventory cannot answer "who needs updates":
- data/downstream-users.json:7-42 includes repos/workflow identifiers only.
- No entries retain refs/tags/SHAs (verified output below).
Related history supports this approach (not a duplicate):
- Create workflow to track downstream users #119 / PR Add downstream users tracking workflow #126 introduced downstream user tracking (internal workflow intent).
- Add downstream health monitoring workflow #39 added downstream health monitoring (quality checks).
- Add workflow for checking recent releases in this repo #113 / PR Add release update workflow #116 added release-update workflow for consumers to run in their own repos, not a centralized cross-repo update report.
Downstream usage currently mixes ref styles, so policy checks are needed:
- elastic/integrations sample uses .../pr-review/rwx with floating major ref.
- elastic/infra-party sample uses .../pr-review/ro with floating major ref.
- strawgate/py-key-value sample uses .../gh-aw-pr-review.lock.yml with branch ref main.

Verification

I ran local verification and sampled downstream workflow files.

$ python - <<'PY'
import json
p='data/downstream-users.json'
d=json.load(open(p))
repos=d['repos']
wf=sum(len(r['workflows']) for r in repos)
with_ref=sum('@' in w for r in repos for w in r['workflows'])
print('repos',len(repos))
print('workflows',wf)
print('entries_with_ref',with_ref)
for r in repos:
    print(r['repo'], len(r['workflows']))
PY
repos 3
workflows 19
entries_with_ref 0
elastic/infra-party 4
elastic/integrations 4
strawgate/py-key-value 11

$ rg "gh-aw-downstream-updates|downstream updates needed" .github/workflows
No matches found.

Sample downstream files fetched from default branches:

elastic/integrations/.github/workflows/claude-pr-review.yml
elastic/infra-party/.github/workflows/claude-pr-review.yml
strawgate/py-key-value/.github/workflows/trigger-pr-review.yml

Detailed Action Plan

Add new internal workflow shim
- Create .github/workflows/gh-aw-downstream-updates-needed.md.
- Follow scheduled-report pattern used by downstream health (.github/workflows/gh-aw-downstream-health.md:1-72).
- Safe output: create-issue (max 1, close older, prefix like [downstream-updates] ).
Improve inventory fidelity (required for correctness)
- Update .github/workflows/gh-aw-downstream-users.md so output entries keep ref metadata instead of stripping it (:110 is the blocker).
- Suggested per-entry shape:
  - repo
  - workflow_file (path where uses: appears)
  - uses_target (path after elastic/ai-github-actions/)
  - ref (floating major tag, semver tag, SHA, or branch)
Detection logic in new workflow
- Input scope: repos in data/downstream-users.json filtered to elastic/* + strawgate/*.
- Fetch latest release/tag from this repo (currently v0.2.5).
- For each entry classify:
  - floating major tag → up-to-date.
  - semver tag older than latest semver → update needed.
  - branch ref like main → policy warning + recommend floating major or pinned release/SHA.
  - SHA refs → optional informational check (advanced mapping can be deferred).
Issue output format (repo-by-repo updates required)
- One section per repo with table:
  - workflow file
  - current ref
  - recommended ref
  - reason
- If no updates needed, call noop with explicit message.
Trigger + docs alignment
- Add .github/workflows/trigger-downstream-updates-needed.yml (daily/weekday schedule + dispatch).
- Since this is internal-only (same pattern as Create workflow to track downstream users #119 intent and downstream-users), document in DEVELOPING.md and gh-agent-workflows/DEVELOPING.md alongside internal workflows guidance.

Related Items

Type	Item	Relevance
Issue	#245	Current request for centralized downstream update reporting
Issue	#119	Introduced downstream user tracking (internal-only intent)
PR	#126	Added downstream-users workflow/data
Issue	#39	Added downstream health monitoring (quality, not update drift)
Issue	#113	Requested consumer release-update workflow
PR	#116	Added release-update workflow
File	`.github/workflows/gh-aw-downstream-users.md:110`	Currently strips version info, blocking precise update detection
File	`.github/workflows/gh-aw-downstream-health.md:81-109`	Adjacent workflow focused on health/error signals
File	`data/downstream-users.json:7-42`	Current downstream inventory source
File	`.github/workflows/trigger-downstream-users.yml:1-16`	Existing internal trigger pattern to mirror

What is this? | From workflow: Issue Triage Agent

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. for issue #245

We'll want to look at the release notes and recent changes and examples in this repo to determine if we should add/remove permissions, workflows, etc. For each repo we'll want to go look at their workflows to detect and report on any relevant drift between what they are using and what they should be using.

Verified. This issue has already been resolved by the following merged Pull Requests:

Fixed in [downstream] add downstream updates-needed internal workflow draft #253 ([downstream] add downstream updates-needed internal workflow draft)
Fixed in Add Downstream Updates Needed workflow #259 (Add Downstream Updates Needed workflow)

Closing this issue as completed based on the Trigger Stale Issues Investigator report.

This issue was labeled stale on 2026-08-10 and has had no further activity for 30 days. Closing automatically. If this issue is still relevant, please reopen it.

What is this? | From workflow: Trigger Stale Issues Remediator

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

Navigation Menu

Repository navigation

Downstream Updates Needed workflow #245

Recommendation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Downstream Updates Needed workflow #245

Description

Activity

github-actions commented on Feb 21, 2026

Recommendation

strawgate commented on Feb 21, 2026

pushkarkurkure172-crypto commented on Aug 11, 2026

github-actions commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions