Docker tag monitor: one PR per config-key + push trigger

[Oseltamivir]

Switch the auto-issue guidance from grouping PRs by framework/image family to one PR per top-level config-key. Add a push trigger scoped to this workflow file so changes can be validated without waiting on the weekly cron.

[claude]

🔴 The new push trigger (lines 4-6) has no branches: filter and no github.event_name guard on the "Create issue for updates" step, so it fires on every push to any branch that touches this workflow file — including the merge of this PR to main. The inputs.dry_run != true gate at line 167 cannot help: for push events, the inputs context is empty (only populated for workflow_dispatch/workflow_call), so null != true is true and a real @claude-tagged issue gets filed using secrets.CLAUDE_PAT. Fix by adding && github.event_name != 'push' to the create-issue step, or scope the push trigger to a non-default branch.

Extended reasoning...

What the bug is. The PR adds a push trigger filtered only by path (.github/workflows/docker-tag-monitor.yml). There is no branches: filter, so any push to any branch that modifies this file fires the workflow. The "Create issue for updates" step at line 166 is gated by:\n\nyaml\nif: steps.check.outputs.has_updates == 'true' && inputs.dry_run != true\n\n\nIn GitHub Actions semantics, the inputs context is populated only for workflow_dispatch and workflow_call events. For push (and schedule) events, inputs.dry_run is null. The expression null != true evaluates to true, so the gate is satisfied and the step runs with GH_TOKEN: ${{ secrets.CLAUDE_PAT }}, hitting Docker Hub and creating/commenting on a real issue with the body @claude Please update the configurations:.\n\nStep-by-step proof that this fires on the merge of this PR itself.\n1. PR #1318 is merged to main. The merge commit modifies .github/workflows/docker-tag-monitor.yml, so the new push-trigger path filter matches.\n2. The workflow runs with github.event_name == 'push'. There is no branches: filter, so main qualifies.\n3. The "Check for new Docker image releases" step queries Docker Hub. If any monitored repo (lmsysorg/sglang, vllm/vllm-openai, etc.) has released a higher-version tag in the last 7 days that matches a suffix already in use, has_updates=true is set.\n4. The "Create issue for updates" step evaluates its if: 'true' == 'true' && null != true → true.\n5. The step uses CLAUDE_PAT to either open a new docker-update issue with title [Auto] Docker Image Updates Available - <date> or comment on an existing one — and the body @-mentions claude, which is the trigger for downstream Claude automation.\n\nThe "Dry run output" step at line 187 has the opposite gate (inputs.dry_run == true); since null == true is false, it never runs on push either. So there is no path where a push event executes as a true dry-run — every push is a production run.\n\nAddressing the refutation. A reasonable counter-reading is that "validate without waiting on the cron" means "run it for real, like cron does, but on demand," and that the author deliberately omitted any push-side dry-run guard because dry_run was only ever meant as a workflow_dispatch opt-in, with the existing open-issue dedup at lines 185–189 acting as the spam mitigation. That reading is internally consistent. The reason this still warrants a comment, not silence: (a) the gate inputs.dry_run != true looks like it should protect non-dispatch runs and silently does not — that's a footgun even if intentional; (b) the push trigger has no branches: filter, so every feature-branch push that edits this file also fires a real run, which is rarely what "validate via push" implies; and (c) the merge of this very PR will trigger a real Docker-Hub check and possibly an @claude-tagged issue with CLAUDE_PAT, which is a one-shot side effect worth surfacing to the author before merge so they can confirm it's intended.\n\nHow to fix. If the author wants push to be truly validating, the minimal patch is one of:\n\nyaml\n# Option A: force-bypass issue creation on push\n- name: Create issue for updates\n if: steps.check.outputs.has_updates == 'true' && inputs.dry_run != true && github.event_name != 'push'\n\n\nor restrict the trigger to a non-default branch:\n\nyaml\non:\n push:\n branches: [docker-monitor-test]\n paths: ['.github/workflows/docker-tag-monitor.yml']\n\n\nIf instead the author intends push to behave like cron (real issues, dedup handles spam), an explicit comment in the workflow stating that — and adding branches: [main] to the push trigger so feature-branch edits don't fire real runs — would make the intent unambiguous.