I have been experimenting with pointing Gemini at public repos and prompting:
"Analyse the GitHub Actions workflows in this repo https://github.com/apache/PROJECT/tree/master/.github and report on possible causes of long run time/high number of runs of GitHub Actions" One output here was: The Problem: Changes to frontend UI files (.ts, .tsx, .less) frequently trigger backend Python unit test runs, and vice versa. Unless paths are explicitly managed on every configuration entry, the entire testing suite runs for micro-commits affecting only one side of the stack. The Fix: Workflows must feature distinct path-routing restrictions: And the suggestion change was: # For frontend workflows on: pull_request: paths: - 'superset-frontend/**' I am no expert on Actions or this project, but thought I'd pass it on in case it is helpful. A second one was: concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: true Which is said to ensure that, when a PR is opened and workflows are running for it, and a further new commit is made to the same PR, the old runs from the first commit are then cancelled - otherwise an open PR that gets 3 more commits pushed, resulst in 3 lots of workflows running for the one PR, 2 of which are redundant. Hope these are useful, or at least food for thought on other possible steamlining improvements. Kind regards, -Bob Thomson On 2026/06/03 18:22:55 Evan Rusackas wrote: > Hi Bob (and all) > > Thanks for the heads up on this. I just opened a swath of PRs that should cut > this down significantly. I’m working with PMC members to > assess/touch-up/review/merge: > > > 1. This PR takes us from 6 Cypress runners down to 5, and takes the > /app/prefix smoke test (only running on master now) down from 2 runners to 1. > https://github.com/apache/superset/pull/40717 > 2. Cypress runners were all spinning up BEFORE they checked to see if they > were needed. This should fix that: > https://github.com/apache/superset/pull/40718 > 3. Gating E2E behind pre-commit. That's such a common failure that we > probably needn't test E2E until it passes. See the caveats here, there are > some visibility and fork-based PR caveats: > https://github.com/apache/superset/pull/40719 > 4. run unit/integration tests on CURRENT python version on PRs, and full > version matrix (3.10-3.12) on master: > https://github.com/apache/superset/pull/40722 > 5. Don't run CodeQL checks on docs-only changes: > https://github.com/apache/superset/pull/40724 > 6. Cancel-in-progress on a few things that churn needlessly on every commit: > https://github.com/apache/superset/pull/40725 > 7. Only build docker on docker-relevant changes: > https://github.com/apache/superset/pull/40723 > > There’s an alternate (radical) solution of just NOT running E2E tests on PRs, > but only running them on master. Sure would “nip it in the bud” cost wise, > but has potential repercussions if we don’t keep a close eye on CI on `master` > > TL;DR: We’re whittling, and will ask for fresh reports (in private ASF Slack > channels, probably) for impact results. > > > -e- > > Evan Rusackas > Preset | preset.io > On Jun 3, 2026 at 10:29 AM -0700, Bob Thomson <[email protected]>, wrote: > > Fewer parallel runs is essential yes - we are at 900/900 GitHub hosted > > runner jobs/slots just now and looking at Superset Actions we can see > > nearly 500 completed Supeset repo action runs in the last hour, some of > > those are up to 25 minutes in execution time, so anything that can be done > > to reduce the share of runner jobs used by Superset is an urgent issue when > > we are at max jobs on runners on a daily basis now. > > > > Thanks. > > > > Kind regards, > > -Bob Thomson, > > ASF Infrastructure > > > > On 2026/05/22 19:54:16 Evan Rusackas wrote: > > > Hi Bob (and everyone here), > > > > > > Thanks for the alert. The unfortunate thing is that this will only get > > > worse as we create/fix more things (security, dependabot, etc). Things > > > only seem to be ramping up. > > > > > > So, agreed, we must whittle. Cypress is the obvious killer (about half > > > the consumption). We’ll try to find ways to whittle away at this (we’re > > > migrating to Playwright, but it takes time). We might also be able to > > > spend less compute and more time by optimizing (or removing) some > > > parallelization here. > > > > > > We’re also looking at moving from dependabot for all dependency bumps (a > > > LOT of PRs) to `renovate` - which might optimize things a bit (bumping > > > dependencies in groups) but we will need to also leave dependabot in > > > place for security-driven fixes as well. > > > > > > As for Cypress tests, we have some “martixification” happening, that I > > > think we can optimize. For the Superset folks reading this, I think we > > > can split out the “app_root” tests to JUST run on merges to `master` > > > rather than every PR. That’ll save ~50% right there, we just have to keep > > > a better eye on CI on `master` (which we haven’t been great about > > > historically, but we’re getting better). > > > > > > Here’s the app_root PR https://github.com/apache/superset/pull/40385 > > > > > > We can also reduce the E2E parallelization shards from 6 to… I dunno… 3 > > > or 4. That’ll save a fair bit of setup time spinning up Superset > > > instances. Tests will run a bit longer, but consume less overall. Seems > > > like a fair tradeoff. > > > > > > Open to other ideas… maybe running fewer GHA workflows in parallel, and > > > having things more sequentially to fail faster (like nothing runs until > > > pre-commit passes, for example). > > > > > > Also, least importantly, we don’t have the access to see how we stack up > > > against other projects, but I sure am curious. > > > > > > Anyone's thoughts/PRs welcomed. > > > > > > Evan Rusackas > > > Preset | preset.io > > > On May 22, 2026 at 4:46 AM -0700, Robert Thomson <[email protected]>, > > > wrote: > > > > Hello, Superset PMC. > > > > > > > > In 2024, the ASF introduced the policy for GitHub Actions usage > > > > across the foundation[1]. The ASF Github shared pool of > > > > Github-hosted runners has been at, or very close to the limit of > > > > 900 jobs most of the time in the past few weeks and this is the > > > > case again today. > > > > > > > > Your project has been identified as being among the top 5 consumers of > > > > build time over the past 7 days and we request that you bring your > > > > usage down by stream-lining long-running builds. Contact Infra for > > > > a consultation if you are unable to streamline your builds further. > > > > > > > > You can use the infra reporting tool[2] to monitor your GHA usage as you > > > > work on stream-lining, as well as locate any bottlenecks in the > > > > workflows. > > > > > > > > Infra will allow you two weeks time (till the 8th of June, 2026) to > > > > progress this, but should you still be above the limits by then, > > > > without a viable path forward, we will be limiting your GHA usage. > > > > > > > > Kind regards, > > > > Bob Thomson, on behalf of ASF Infrastructure. > > > > > > > > > > > > [1] https://infra.apache.org/github-actions-policy.html > > > > [2] > > > > https://infra-reports.apache.org/#ghactions&project=superset&hours=24&limit=15&group=name > > > >
