sadpandajoe commented on code in PR #42488:
URL: https://github.com/apache/superset/pull/42488#discussion_r3678928120


##########
.github/workflows/superset-docs-deploy.yml:
##########
@@ -47,17 +37,68 @@ jobs:
 
         env:
           SUPERSET_SITE_BUILD: ${{ (secrets.SUPERSET_SITE_BUILD != '' && 
secrets.SUPERSET_SITE_BUILD != '') || '' }}
+
+  # Master gets frequent, sometimes bursty pushes, and each one can trigger a
+  # deploy attempt. Rather than let every superseded attempt get force-killed
+  # by the build-deploy concurrency group below (which shows up as a
+  # `cancelled` — i.e. red/failing-looking — check on that commit), have each
+  # run check up front whether it's still building master's current tip and,
+  # if not, skip cleanly. Deliberately outside the docs-deploy-asf-site
+  # concurrency group so it runs immediately for every trigger without
+  # blocking or being blocked by anything.
+  check-freshness:
+    runs-on: ubuntu-26.04
+    outputs:
+      is-current: ${{ steps.check.outputs.is-current }}
+    steps:
+      - name: "Check whether this is still master's current commit"
+        id: check
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          BUILD_SHA: ${{ github.event.workflow_run.head_sha || github.sha }}
+          EVENT_NAME: ${{ github.event_name }}
+        run: |
+          # workflow_dispatch is a deliberate, one-off action (e.g. to deploy
+          # a specific ref) rather than something racing other triggers, so
+          # it always bypasses the freshness gate below.
+          if [ "${EVENT_NAME}" = "workflow_dispatch" ]; then
+            echo "is-current=true" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+
+          latest_sha="$(gh api "repos/${{ github.repository }}/commits/master" 
--jq .sha)"
+          if [ "${latest_sha}" = "${BUILD_SHA}" ]; then
+            echo "is-current=true" >> "$GITHUB_OUTPUT"
+          else
+            echo "is-current=false" >> "$GITHUB_OUTPUT"
+            echo "::notice::master has moved on to ${latest_sha} since 
${BUILD_SHA} was triggered — a newer run will deploy it, so skipping this one."
+          fi
+
   build-deploy:
-    needs: config
+    needs: [config, check-freshness]
+    # Only the run for master's current tip proceeds; anything superseded
+    # already skipped at check-freshness above instead of landing here.
     # For workflow_run triggers, only deploy when the triggering run originated
     # from this repository (not a fork), ensuring the checked-out code and any
     # local actions executed with deploy credentials are trusted.
     if: >-
       needs.config.outputs.has-secrets &&
+      needs.check-freshness.outputs.is-current == 'true' &&
       (github.event_name != 'workflow_run' ||
        github.event.workflow_run.head_repository.full_name == 
github.repository)
     name: Build & Deploy
     runs-on: ubuntu-26.04
+    # Serialize deploys: the action pushes to apache/superset-site without
+    # rebasing, so concurrent runs race on the final push and the loser fails
+    # with `! [rejected] asf-site -> asf-site (fetch first)`. Cancel any
+    # in-progress run as soon as a newer one starts — the destination repo
+    # isn't touched until the final push step, so canceling mid-build is safe,
+    # and the freshest content always wins. The check-freshness gate above
+    # means it should be rare for more than one run to reach this point, but
+    # this stays as a backstop against the actual push race.
+    concurrency:
+      group: docs-deploy-asf-site
+      cancel-in-progress: true

Review Comment:
   Could we close the gap between the freshness check and entering this 
concurrency group? An older run can cache `is-current=true`, finish `config` 
after a newer run has started, then enter here later and cancel the newer 
deployment.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to