rusackas opened a new pull request, #42148: URL: https://github.com/apache/superset/pull/42148
### SUMMARY On PR #42114, both required lint checks (`lint-check` from PR Lint and `lint-test` from Helm lint) showed as **cancelled** in the merge box despite green duplicates existing for the same head SHA, blocking an approved PR from merging. What happened, reconstructed from the check-run/timeline APIs: 1. PR Lint and Helm lint are the **only** two `pull_request` workflows that trigger on the `edited` activity type, so when a PR is opened and its title/description is edited shortly after (which contributors do constantly), each workflow gets **two runs for the same head SHA**. 2. On a first-time contributor's PR, all of those runs sit in `action_required` until a maintainer clicks "Approve and run", which launches them **near-simultaneously**. 3. The per-PR `concurrency` group with `cancel-in-progress: true` then has the duplicate runs cancel each other — and because approval order is arbitrary, the run created *later* can lose the race to the run created *earlier*. 4. GitHub's merge box resolves required checks from the **newest check suite** per check name, so when the newer run is the cancelled one, the PR shows a permanently-cancelled required check. It stays wedged until a maintainer notices and manually re-runs the cancelled run (which is how #42114 was unblocked). The fix: - **`pr-lint.yml`**: keep the `edited` trigger (re-linting the title on edit is the point of this workflow), but switch to `cancel-in-progress: false`. The concurrency group still serializes runs per PR; queued duplicates now run to completion instead of cancelling each other. The job takes ~20 seconds, so the runner cost of finishing a redundant run is negligible next to a wedged PR. - **`superset-helm-lint.yml`**: drop the `edited` trigger entirely — title/body edits cannot change chart contents, and the `helm/**` paths filter already scopes the workflow — and likewise switch to `cancel-in-progress: false` so a multi-push approval race can't strand a cancelled required check either. Note the same race is theoretically possible on any workflow with `cancel-in-progress: true` when a contributor pushes multiple commits before workflow approval, but the `edited`-triggered same-SHA duplication is what makes these two workflows hit it routinely; this PR scopes the change to them. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF N/A (CI behavior) ### TESTING INSTRUCTIONS - `pre-commit` (check-yaml, zizmor GHA audit, helm-docs) passes on both files. - Behavior can be observed on any first-time-contributor PR that edits its description after opening: previously each edited-triggered workflow left one cancelled run for the head SHA after workflow approval; with this change all queued runs complete. ### ADDITIONAL INFORMATION <!--- Check any relevant boxes with "x" --> <!--- HINT: Include "Fixes #nnn" if you are fixing an existing issue --> - [ ] Has associated issue: - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
