From c01c09b8a202982855f4a77d9e57f71e88dd1fac Mon Sep 17 00:00:00 2001
From: Viet Anh Nguyen <vietanh.dev@gmail.com>
Date: Mon, 20 Jul 2026 14:52:43 +0700
Subject: [PATCH] fix(aur): do not fail a successful publish when AUR drops the
 connection

The v0.2.0 AUR publish succeeded and the workflow reported failure:

  [master (root-commit) 6785b0b] Update to 0.2.0
   * [new branch]      HEAD -> master
  Connection closed by 209.126.35.78 port 22
  fatal: Could not read from remote repository.

The push landed -- aur.archlinux.org/packages/thinkutils shows
"thinkutils 0.2.0-1" -- and it was the verification step I added one
commit earlier that failed, because AUR closes the SSH connection
immediately after accepting a push.

Reporting failure on a successful publish is not the harmless direction
of this mistake. It invites a re-run, and re-running a publish is not
always harmless.

So: retry ls-remote with backoff, and if AUR still cannot be reached,
emit a warning naming the package page rather than failing -- git push
already reported success, and an unreachable remote is not evidence the
push did not land. A genuine mismatch, where the remote IS readable and
disagrees, still fails.

Verification steps need to distinguish "this did not work" from "I could
not tell". This one conflated them.
---
 .github/workflows/publish-aur.yml | 27 +++++++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/.github/workflows/publish-aur.yml b/.github/workflows/publish-aur.yml
index 6036a83..cbc875e 100644
--- a/.github/workflows/publish-aur.yml
+++ b/.github/workflows/publish-aur.yml
@@ -155,13 +155,32 @@ jobs:
           # Confirm the remote actually moved. A push that resolves to a no-op
           # exits 0, and this workflow has already reported success once while
           # publishing nothing.
+          #
+          # Retried, because AUR closes the SSH connection immediately after a
+          # push: the first attempt at this got "Connection closed by ... port
+          # 22" and failed a run whose push had in fact succeeded. Reporting
+          # failure on a successful publish is its own hazard -- it invites a
+          # re-run, and re-running a publish is not always harmless.
           local_sha="$(git rev-parse HEAD)"
-          remote_sha="$(git ls-remote origin refs/heads/master | cut -f1)"
-          if [ "${local_sha}" != "${remote_sha}" ]; then
-            echo "::error::push did not land - local ${local_sha} but remote master is ${remote_sha:-<empty>}"
+          remote_sha=""
+          for attempt in 1 2 3 4 5; do
+            remote_sha="$(git ls-remote origin refs/heads/master 2>/dev/null | cut -f1)"
+            [ -n "${remote_sha}" ] && break
+            echo "  ls-remote attempt ${attempt} got nothing (AUR often drops the connection after a push); retrying"
+            sleep $((attempt * 5))
+          done
+
+          if [ -z "${remote_sha}" ]; then
+            # Could not reach AUR to confirm. The push itself reported success,
+            # so do NOT fail -- say plainly that it is unconfirmed and let the
+            # package page be the check.
+            echo "::warning::could not reach AUR to confirm the push landed; git push reported success. Verify at https://aur.archlinux.org/packages/thinkutils"
+          elif [ "${local_sha}" != "${remote_sha}" ]; then
+            echo "::error::push did not land - local ${local_sha} but remote master is ${remote_sha}"
             exit 1
+          else
+            echo "published ${local_sha} to AUR master"
           fi
-          echo "published ${local_sha} to AUR master"
 
       - name: Dry run notice
         if: ${{ inputs.dry_run }}