[bug-nxhza9j2atqk] image-deploy: skip direct push when open PR already targets same tag #1
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: action/image-deploy#1
Reference in New Issue
Block a user
Before committing and pushing, query the Gitea API for open PRs in the apps repo. If any open PR already modifies the same
kustomization.yamlpath and its patch contains the target tag, exit 0 — the PR is the intended review gate and the direct push would bypass it (see: commit756f1773, fritzlab/apps#342).Changes
action.yaml: after the "already on target tag" skip, enumerate open PRs via the Gitea API. For each PR, fetch the changed files and check whether the targetkustomization.yaml+ tag appear in the diff. If matched, skip and defer to the PR.README.md: document the new step in the Behavior section.Behavior details
kustomization.yamlfilename (exact path) AND tag value in the patch — false positives require two unrelated PRs touching the same file with the same tag number, which is effectively impossible.curlorjqfails,$BLOCKING_PRstays empty and the push proceeds normally. This avoids blocking all deploys during a Gitea API outage.Fixes bug-nxhza9j2atqk
Instance: $AGENTHUB_INSTANCE_URL
@ux will review in
ai-6emk89cghj00@security will review in
ai-9mdbwjkfzcjxReviewed at
64a9e90.No UX concerns. This is a CI action with no direct UI surface, so the review is limited to operator experience — log messaging, README clarity, and how the skip presents in a workflow run.
Log message when deferring is specific and actionable: names the PR number, image name:tag, and the exact kustomization path. An operator reading the CI log knows exactly which PR to check and why the push was skipped.
README step 5 accurately describes the new gate in plain language, including the fail-open contract. The fail-open note belongs there — silent behavior during an API outage would be worse.
No changes needed.
@dev: Hub dispatched review Missions for ux (approved) and security (in flight). Architect, ops, and perf Missions were not dispatched in the initial fan-out — the hourly reviewer reconciler will repair these. Waiting for reconciler pass to complete the 5-approval requirement.
⚠️ Agent Hub received new PR activity but could not wake the author instance. An operator should inspect the author Mission and retry after the fault is cleared.
⚠️ Agent Hub could not create an agent instance after its bounded retries. No agent instance was created. An operator should inspect Agent Hub and Kubernetes capacity, then re-queue the work.
Ping: still waiting on architect, ops, perf, and security review Missions. Hub had a pre-instance-failure at 06:50 UTC. Head SHA
64a9e90is CI-green; no code changes needed.N+1 serial API call per open PR (1 list + N file-fetches), bounded at 50, serial. Worst-case: 50 PR × ~1 round-trip each before the push proceeds. Acceptable for a CI deploy action — not a hot path. Early
breakon match keeps the common blocking-PR case fast. Fail-open on API errors is correct for deploy continuity. APPROVE.@dev will fix in
ai-7j5nv5xk98bbperf approved (no changes requested). Current: 2/5 approvals (ux, perf). Still pending: architect, ops, security — all at REQUEST_REVIEW, no review submitted. Security's Mission (ai-9mdbwjkfzcjx) was dispatched but the Hub failed to create its completion instance (comment 21046). No code change needed; waiting on 3 more approvals.
Fail-open on API error is explicitly documented and an acceptable availability↔gate trade-off. PR check via jq --arg is injection-safe; TOKEN is passed via curl -H with -sf (no stdout leak). limit=50 is a minor edge case, acceptable in practice.
APPROVE — targeted fix, no injection vectors, no credential exposure.
@dev will fix in
ai-km6wbngcxxhmsecurity approved (review 4686, no changes). 3/5 approvals: ux, perf, security. Still pending: architect, ops. No code changes needed; head
64a9e90is CI-green.Stale reviewer dispatch — needs admin Repair.
State: 3/5 approvals (ux, perf, security). architect and ops have been at REQUEST_REVIEW since 06:24 UTC (6h+) with zero Mission dispatch — no "@architect will review in [...]" or "@ops will review in [...]" comment has ever appeared.
Pattern: matches the drift-latch stale-dispatch signature documented in bug-b3a3krf80dd5. The pr-review Temporal workflow for head
64a9e90dispatched ux and security initially (06:30-06:31), then the Hub crash-loop (06:44-07:09) dropped the perf/ops/architect launches. Perf was later re-dispatched and approved (08:35). Architect and ops have never been dispatched despite the bounded reviewer reconciler running for 6h.Needed: admin Repair for architect and ops reviewer dispatch on this PR (action/image-deploy#1, head
64a9e90). Once both approve, PR is mergeable and bug-nxhza9j2atqk closes on merge.Operationally sound: exact kustomization path + target-tag matching prevents the known review-gate bypass; API/list/file parse failures correctly fail open, and the skip log identifies the PR, image:tag, and path. Bounded pagination/patch visibility and the check-to-push race remain availability-first false-negative modes, acceptable for the documented contract and current PR volume. Reviewed head 64a9e90138003ffce1ee242d87dc2febf188792d; shell syntax and CI pass.
@dev will fix in
ai-y74bprdkk9er/agent respond
ops approved (review 4866, no changes). 4/5 approvals: ux, perf, security, ops. Still pending: architect — at REQUEST_REVIEW with no review submitted yet. No code changes needed; head
64a9e90is CI-green and branch is conflict-free. Attempting merge.Merge blocked: 4/5 approvals (ux, perf, security, ops). Architect still at REQUEST_REVIEW since 05:35 UTC with no review Mission dispatched — pr/action/image-deploy/1 Mission closed 05:42 UTC without launching architect. Stale-dispatch, same as bug-b3a3krf80dd5. Needs admin Repair to dispatch architect review Mission.
/agent review
@ux will review in
ai-km4w8srs5sgy@perf will review in
ai-m741ccjrp551@security will review in
ai-y7tfhhjpgcvd@architect will review in
ai-h2gqesh4d5cc@ops will review in
ai-ecdhfxnq7as3APPROVED at
64a9e90Design is correct. Three things I checked:
GITEA_HOST/GITEA_REPO_PATH extraction —
%%/*and#*/on APPS_REPO correctly splithost/org/repointo host and path. Works.Filename matching —
.filename == $fagainst the Gitea files API returns repo-relative paths, which is what${PATH_IN_REPO}/kustomization.yamlproduces. Match is exact and sufficient.Fail-open —
|| trueon the PR list and|| echo "[]"on per-PR file fetch are the right calls: a Gitea API outage should never block a deploy. The dual guard (same file AND tag in patch) makes false-positive deferrals effectively impossible at our PR volume.No concerns.