snazy commented on code in PR #2156:
URL: https://github.com/apache/polaris/pull/2156#discussion_r2227987763


##########
releasey/04-build-and-test.sh:
##########
@@ -0,0 +1,118 @@
+#!/bin/bash
+#
+# 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.
+#
+
+#
+# Build and Test Script
+#
+# Builds Polaris completely and runs regression tests to verify the release.
+# Cloud-specific tests are disabled by default and require proper credentials
+# to be configured in the environment.
+#

Review Comment:
   Ah, I recall now. Statuses and check-runs are different things. And there's 
no "combined check-runs conclusion".
   Yes, you'd need to "manually combine" via all `conclusion` fields (not the 
`status` field). 
   
   "Successful conclusions are both `success` _and_ `skipped`, everything else 
**including `null`** is in this use case a failure.
   
   The annoying thing about check-runs is that the `name` of the check-runs is 
only the name of the job of a workflow, not the "full name" (with the name of 
the workflow). I think, that's okay-ish to only say that some check failed.
   
   Considering all check-runs of a commit is probably okay for now, as all 
checks are required. However, if there is ever a check (like a workflow job) 
that is _not_ required and that fails, the "ready-to-release" verification 
would fail as well, because it's a bit more complicated to know which checks 
are required by a branch protection rule.



-- 
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]

Reply via email to