sadpandajoe commented on code in PR #42488:
URL: https://github.com/apache/superset/pull/42488#discussion_r3718448246
##########
.github/workflows/superset-docs-deploy.yml:
##########
@@ -47,17 +37,69 @@ 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:
+ # Sparse checkout: this job's only job is to be fast, so it fetches
+ # nothing but the freshness-check script itself.
+ - name: Checkout freshness-check script
+ uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 #
v7.0.1
+ with:
+ persist-credentials: false
+ sparse-checkout: |
+ .github/workflows/scripts
+ sparse-checkout-cone-mode: false
+ - 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 }}
+ REPO: ${{ github.repository }}
+ OUTPUT_NAME: is-current
+ run: .github/workflows/scripts/check-docs-deploy-freshness.sh
+
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)`. Queue instead of
+ # canceling: a run that already passed check-freshness can still be
+ # sitting in the queue for a runner when a newer run starts and finishes
+ # first. cancel-in-progress would let that stale, queued run kill the
+ # newer run's in-progress deploy the moment it's finally scheduled, and
+ # then skip itself at the re-check below — losing the deploy entirely.
+ # Queuing means the stale run just waits its turn and then no-ops at the
+ # re-check, so the fresher content that already deployed is never
+ # clobbered or lost. The check-freshness gate above means it should be
+ # rare for more than one run to reach this point, so the queue stays
+ # short in practice.
+ concurrency:
+ group: docs-deploy-asf-site
+ cancel-in-progress: false
Review Comment:
The reverted head removes `queue: max`, so GitHub’s default single pending
slot can still replace the current-tip deployment with a delayed stale run that
then no-ops. Could we use a queue-preserving design that also passes the
repository validator?
--
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]
