Yicong-Huang commented on code in PR #5557: URL: https://github.com/apache/texera/pull/5557#discussion_r3371061386
########## .github/workflows/benchmarks.yml: ########## @@ -0,0 +1,327 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + +# Texera benchmarks — bench-agnostic umbrella workflow. +# +# This file is the single CI entry for ALL Texera performance benchmarks +# (currently Arrow Flight E2E; JMH and others land here as well). The +# workflow knows nothing about specific benches — bin/run-benchmarks.sh +# is the opaque entry point that owns which benches run and where their +# outputs land under bench-results/. Adding a new bench is: +# 1. Append the run command to bin/run-benchmarks.sh. +# 2. Add a `Publish <chart-name>` step block below pointing at the +# bench's JSON output file with the right `tool:` setting. +# This workflow file otherwise stays unchanged. +# +# Triggering — mirrors amber-integration's label gate (NOT file paths): +# - PR: runs only when one of the labels mapped to the amber-integration +# stack in required-checks.yml's LABEL_STACKS is present on the PR. +# Labels are applied by the .github/labeler.yml workflow on opened / +# synchronize, so we wait for that workflow to complete before +# deciding (same pattern required-checks.yml uses). +# - push to main: always runs (same trimmed grid as PR for quick post- +# merge signal) and publishes to gh-pages. +# - schedule (weekly): runs the full 36-config sweep and publishes to +# gh-pages — this is the authoritative long-term baseline. +# - workflow_dispatch: manual full-grid run (no publish; bring-your-own +# trigger for ad-hoc exploration). +# +# Two modes via BENCH_MODE env (read by the bench Scala main): +# pr — 3 configs × 20 batches, ~5 min (PR + push-to-main) +# full — 36 configs × 200 batches, ~50-60 min (schedule + dispatch) +# +# Non-blocking: this workflow is NOT included in required-checks.yml's +# `required-checks` aggregator, so its result doesn't gate merges even +# when it fails. Adding it to branch protection later is a deliberate +# .asf.yaml change. +# +# Permissions: +# contents: write — needed by benchmark-action's auto-push to gh-pages. +# PR runs (which GitHub auto-downgrades to read-only on forks) gate +# auto-push off via the event check, so the missing write is never +# exercised. + +name: Benchmarks Review Comment: first let's make it informative. I plan to optimize scala <-> python data transfer, and this bench information can be useful even compared manually. Whether we want to make it required and blocking PR merge, can be discussed later. -- 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]
