jmckenzie-dev commented on code in PR #2554: URL: https://github.com/apache/cassandra/pull/2554#discussion_r1286297914
########## .build/config/pipelines.cfg: ########## @@ -0,0 +1,78 @@ +# 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. + +# +# Contains definitions of all pipelines in the system. Pipelines are composed of a collection of jobs; see jobs.cfg for per-job details +# + +# Format is expected to be as follows: +# pipeline:<name> +# job1 +# job2 +# job3 +# ... +# jobN +# pipeline_2:<name> +# etc +# +# End of a pipeline is determined by either start of subsequent or EOF + +# All jobs in the pre-commit pipeline must run within constraints and pass +# before a commit is merged upstream. Committers are expected to validate +# and sign off on this if using non-reference CI environments. +# +# Failure to do so will lead to commits being reverted. +pipeline:pre-commit Review Comment: > do we really have this defined like this In circle, the config has "javaN_pre-commit_tests" and "javaN_separate_tests". Given the `long`, `vnode` vs. `novnode`, `large`, `burn`, etc suites, things that we don't expect to fail often or change often but we'd still like to run with some periodicity, in the interest of both saving on resources as well as making things simpler for folks running their own CI, we've inherited the "pre vs. post" designation for these suites. If someone downstream just wants to run the full post-commit suite matrixed across all params (cdc vs. non, JDK versions, vnode vs. none, etc), I don't think anyone's _stopping_ them from doing so. My personal opinion: we're targeting the point of dimishing returns in catching defects from where we drew the line on pre-commit vs. post-commit in terms of energy consumption, compute time, costs, etc. Especially if we end up with a cloud account for the project that committers can use to run tests, being efficient with our resource usage in this context really matters. -- 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]
