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


##########
.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:
   Fair point, @sadpandajoe. The gap that actually matters is right before the 
push to superset-site, not the concurrency group itself. Added a re-check there 
so a stale run skips the deploy step instead of overwriting a fresher one that 
already landed.



##########
.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: |

Review Comment:
   I don't think we have any harness for testing GH Actions trigger logic here, 
just the static yaml/zizmor checks. Standing one up would mean extracting the 
shell into scripts and picking something like `act` to run it, which feels like 
its own project rather than something to bolt onto this fix. Worth a follow-up 
issue if it becomes a recurring pain point.



-- 
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