felipepessoto commented on PR #12388: URL: https://github.com/apache/gluten/pull/12388#issuecomment-5135529692
@philo-he, @zhouyuan #### 1. Delta own workflow - done in this PR I've split it. `delta_spark_ut.yml` already had its own `build-native-lib-centos-7` for the `workflow_dispatch`/`schedule` path, so it was mostly dropping `workflow_call`, adding a `pull_request` trigger with a Delta `paths:` filter, and deleting the caller-side jobs. #### 2. Sharing the native lib Worth doing, but as a follow-up: I measured `build-native-lib-centos-7` at a median of **10.4 min** over the last 16 runs, so it's ~10 min on `gluten-delta` PRs, which is why I didn't block the split on it. @zhouyuan one wrinkle on the mechanism: artifacts are scoped to a workflow **run**, and there's no cross-workflow `needs`, so the Delta workflow would have to find the sibling run and poll it, both start from the same PR event, so it'd be waiting on a race. A **cache** avoids that entirely since it's populated by push-to-`main`, which is what `velox_backend_cache.yml` already does for ccache. Your fallback point is right and comes for free: a miss just builds. Two things to get right first: the key must cover `cpp/**`, the build flags and the base image (a too-narrow key is harmless for ccache, which re-hashes each file itself, but for a *prebuilt* lib it means silently testing a stale binary), and the repo is already at **10.63 GB against GitHub's 10 GB** cache quota, so entries are being evicted, presumably why the other workflows restore from Stash first. #### 3. Sharding - done in this PR Agreed, and it's cheap. A shard is ~9 min fixed setup plus ~135 min of tests, so ~91% shards away: 4 -> 8 shards takes the slowest shard from ~148 min to ~74 min for ~7% more runner-minutes. This also matches delta-io/delta's own `spark_test.yaml`, which runs these suites with `NUM_SHARDS: 8` and `TEST_PARALLELISM_COUNT=4`. Memory is unchanged (each shard is its own runner), and no baseline regeneration is needed, the gate compares `(suite, test)` sets, so it doesn't care how suites are distributed. #### 4. Multiple Spark versions The workflow already takes `spark_version` and `delta_ref` inputs. The real cost is the **baseline**: `known-failures.txt` currently holds 737 entries specific to Delta 4.2 + Spark 4.1. Every additional combination needs its own baseline file plus a bootstrap run to generate it, and then ongoing triage when it drifts. Each leg is also ~570 runner-minutes. I wanted to first have the most current version running to prove the approach is right and then expand to more Delta/Spark versions. -- 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]
