nchammas commented on code in PR #59695:
URL: https://github.com/apache/spark/pull/59695#discussion_r4345973401
##########
dev/merge_spark_pr.py:
##########
@@ -2205,19 +2224,53 @@ def get_current_ref():
return ref
+def jira_is_live():
+ """Quick liveness probe for the SPARK JIRA backend, to decide whether to
touch JIRA at all.
+
+ Returns False -- so the merge proceeds with JIRA disabled rather than
failing or hanging --
+ when JIRA is down, errors out, or takes longer than JIRA_READ_TIMEOUT to
answer. The ASF JIRA
+ instance goes down for infra maintenance often enough to be worth
tolerating.
+ """
+ # issues.apache.org is a reverse proxy in front of several backends, so
the front door can be
+ # up while the backend serving SPARK returns 503. Probe a SPARK-specific
endpoint so the result
+ # reflects whether SPARK operations will actually work. A 4xx still means
a backend answered
+ # (up); a 5xx (e.g. that 503) or a connection/timeout error means it is
effectively dead.
+ url = "%s/rest/api/2/project/SPARK" % JIRA_API_BASE
+ try:
+ with urlopen(Request(url), timeout=JIRA_READ_TIMEOUT):
+ return True
+ except HTTPError as e:
+ return e.code < 500
+ except Exception:
+ return False
+
+
def initialize_jira():
- # JIRA access is mandatory: a successful merge must resolve the associated
ticket. Bail out
- # early -- before any git work -- if a prerequisite is missing, rather
than silently merging
- # and leaving the JIRA open (which is easy to miss and tedious to
reconcile after the fact).
- global asf_jira
+ # A successful merge should resolve its ticket, so JIRA access is normally
mandatory and we
+ # bail out early -- before any git work -- on a missing library or
credentials. But the ASF
+ # JIRA instance is not always up; probe it first and, if it is unreachable
or too slow, disable
+ # JIRA for this run (asf_jira stays None) and let the merge proceed,
reconciling by hand later.
+ global asf_jira, jira_disabled
asf_jira = None
+ jira_disabled = False
jira_server = {"server": JIRA_API_BASE}
+ if not jira_is_live():
+ jira_disabled = True
+ print_error(
+ "JIRA is unreachable (%s did not answer within %gs); disabling all
JIRA steps for "
Review Comment:
Nit: We should use f-strings or `.format` rather than old-style `%`
formatting (here and elsewhere in this PR).
##########
dev/merge_spark_pr.py:
##########
@@ -2205,19 +2224,53 @@ def get_current_ref():
return ref
+def jira_is_live():
+ """Quick liveness probe for the SPARK JIRA backend, to decide whether to
touch JIRA at all.
+
+ Returns False -- so the merge proceeds with JIRA disabled rather than
failing or hanging --
+ when JIRA is down, errors out, or takes longer than JIRA_READ_TIMEOUT to
answer. The ASF JIRA
+ instance goes down for infra maintenance often enough to be worth
tolerating.
+ """
+ # issues.apache.org is a reverse proxy in front of several backends, so
the front door can be
+ # up while the backend serving SPARK returns 503. Probe a SPARK-specific
endpoint so the result
+ # reflects whether SPARK operations will actually work. A 4xx still means
a backend answered
+ # (up); a 5xx (e.g. that 503) or a connection/timeout error means it is
effectively dead.
+ url = "%s/rest/api/2/project/SPARK" % JIRA_API_BASE
+ try:
+ with urlopen(Request(url), timeout=JIRA_READ_TIMEOUT):
+ return True
+ except HTTPError as e:
+ return e.code < 500
+ except Exception:
+ return False
+
+
def initialize_jira():
- # JIRA access is mandatory: a successful merge must resolve the associated
ticket. Bail out
- # early -- before any git work -- if a prerequisite is missing, rather
than silently merging
- # and leaving the JIRA open (which is easy to miss and tedious to
reconcile after the fact).
- global asf_jira
+ # A successful merge should resolve its ticket, so JIRA access is normally
mandatory and we
+ # bail out early -- before any git work -- on a missing library or
credentials. But the ASF
+ # JIRA instance is not always up; probe it first and, if it is unreachable
or too slow, disable
+ # JIRA for this run (asf_jira stays None) and let the merge proceed,
reconciling by hand later.
Review Comment:
If we're OK with this, we should think about decoupling this in a way that
allows us to revisit a merged PR using the merge script and have it update the
Jira ticket then. This is similar to how you can revisit a merged PR to cherry
pick it to additional branches.
Not necessarily something to implement in the current PR; just thinking out
loud.
--
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]
