alissa-tools-github-revloop 0.19.0__tar.gz → 0.20.0__tar.gz

{alissa_tools_github_revloop-0.19.0/src/main/alissa_tools_github_revloop.egg-info → alissa_tools_github_revloop-0.20.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: alissa-tools-github-revloop
-Version: 0.19.0
+Version: 0.20.0
 Summary: ALISSA-TOOLS-GITHUB-REVLOOP
 Home-page: https://alissa.app
 Author: Fahera

{alissa_tools_github_revloop-0.19.0 → alissa_tools_github_revloop-0.20.0}/src/main/alissa/tools/github/revloop/ghclient.py

@@ -899,12 +899,28 @@ class GitHub:
         app; see ACTIONS_FALLBACK_NOTE for why that is accepted here and how the
         answer says so.
 
-        COST: this path costs one call for the run listing plus one per kept
-        workflow, where the read it replaces cost one. It is taken only where
-        the alternative is a permanent CHECKS_UNKNOWN, and only on the rollup
-        reads the caller already decided to make -- the gate's existing
-        per-round caching is what bounds how often that is. On this fleet's
-        repos (one or two workflows per commit) it is two or three calls.
+        COST, stated exactly, because it is the sentence an operator would size
+        rate-limit headroom from: this path costs one call for the run listing
+        plus one per KEPT workflow, where the read it replaces cost one.
+
+        Nothing caches that on the production path. `loop._dry_run_rollups` is
+        the only rollup memo and only the dry-run branch reads it, so what
+        bounds how often the cost is paid is the POLL INTERVAL -- both while
+        `_checks_at_spawn` holds a round on `checks_spawn_wait_seconds` and
+        while `_gate_on_checks` holds a finished verdict on
+        `checks_wait_seconds`, each of which re-reads the rollup every pass.
+
+        Nor is the fan-out bounded. CHECK_RUN_PAGE_LIMIT bounds the run
+        LISTING; the number of kept workflows is whatever the sha carries, and
+        each one costs a `jobs` call with `_api`'s 60s timeout, so a
+        many-workflow sha turns one rollup read into a long synchronous stall
+        inside a poll pass that has other PRs to decide. On this fleet's repos
+        (one or two workflows per commit) it is two or three calls; that is a
+        fact about these repos, not a bound this code enforces.
+
+        The trade is still worth taking where it applies: the alternative there
+        is a permanent CHECKS_UNKNOWN, which costs one call and can never
+        approve.
         """
         runs = self._rollup_listing(
             f"repos/{owner}/{repo}/actions/runs",
@@ -919,14 +935,26 @@ class GitHub:
 
     @staticmethod
     def _latest_run_per_workflow(runs: list[dict]) -> list[dict]:
-        """One run per workflow: the most recent.
-
-        A sha carries more than one run of the same workflow whenever it was
-        triggered more than once -- a re-run shares its run id, but a distinct
-        trigger event (a `push` and a `pull_request` on the same commit, a
-        workflow re-dispatched by hand) creates a distinct run. Reading all of
-        them would judge the commit on a superseded attempt: an earlier failed
-        run whose re-trigger passed would hold the head red forever.
+        """One run per workflow AND trigger event: the most recent.
+
+        Two different facts are being separated here, and collapsing them was a
+        fail-open bug.
+
+        SUPERSEDED ATTEMPTS collapse. A sha carries more than one run of the
+        same workflow for the same event whenever it was triggered again -- a
+        re-run shares its run id, a re-dispatch does not. Reading all of them
+        would judge the commit on a superseded attempt: an earlier failed run
+        whose re-trigger passed would hold the head red forever.
+
+        DISTINCT EVENTS DO NOT. A workflow declaring `on: [push, pull_request]`
+        produces a `push` run and a `pull_request` run for the same sha, and
+        GitHub publishes a check run per job for BOTH -- so the read this
+        stands in for reports both. Keying on `workflow_id` alone dropped the
+        lower `run_number` of the pair unread, and when the dropped one was the
+        red one the fallback answered GREEN for a commit whose real rollup is
+        red. That is the fail-open direction this whole component exists to
+        avoid, so the key carries `event` as well. A re-run preserves its run's
+        `event`, so the superseded-attempt collapse above is unaffected.
 
         Recency is `run_number` then `id`, both monotonic per workflow and both
         integers -- deliberately not a timestamp string, which is the field a
@@ -938,7 +966,7 @@ class GitHub:
         for index, run_ in enumerate(runs):
             workflow_id = run_.get("workflow_id")
             key: object = (
-                ("workflow", workflow_id)
+                ("workflow", workflow_id, str(run_.get("event") or ""))
                 if workflow_id is not None
                 else ("unidentified", index)
             )

{alissa_tools_github_revloop-0.19.0 → alissa_tools_github_revloop-0.20.0}/src/main/alissa/tools/github/revloop/loop.py

@@ -407,6 +407,22 @@ CHECKS_FAILING_LINE = "- `{name}` — {conclusion}{url}"
 
 # Prepended when the gate held the approve for the whole wait bound and the
 # rollup still had not settled, so the verdict lands as a COMMENT.
+# Prepended to an APPROVE whose green came from the Actions-API fallback rather
+# than the check-runs rollup. Not a caveat on the review -- the code verdict is
+# unchanged -- but on the EVIDENCE behind the approve: the fallback cannot see a
+# check run posted by a third-party check app, so "green" here means "every
+# Actions-produced context passed", which is the same thing only on an
+# Actions-only repo.
+CHECKS_FALLBACK_LEAD = (
+    "**CI rollup at `{sha}` read through the Actions API.** This deployment's "
+    "credential cannot read check runs (GitHub does not offer the `Checks` "
+    "permission on fine-grained PATs), so the head was confirmed green from its "
+    "workflow runs and jobs instead. That read sees every GitHub-Actions "
+    "context and no third-party check app's, so on an Actions-only repo it is "
+    "the same answer — flagging the path because an approve is the operator's "
+    "merge cue.\n\n"
+)
+
 CHECKS_UNSETTLED_LEAD = (
     "**Recorded as a comment, not an approve — the CI rollup at `{sha}` never "
     "concluded.**\n\n"
@@ -466,10 +482,18 @@ CHECKS_STILL_RUNNING = "Still running at the bound: {names}."
 # which waited on nothing and so cannot describe anything as being "at the
 # bound" (see CHECKS_AT_SPAWN_GATE_OFF).
 CHECKS_GATE_OFF_DETAIL = "Still running when the round was queued: {names}."
+# Deliberately does NOT tell the operator to grant `checks: read`, which is what
+# it said before the Actions fallback existed. GitHub does not offer the `Checks`
+# permission on fine-grained PATs at all, and a rollup that reaches UNKNOWN on
+# such a deployment has ALREADY tried the Actions read and failed -- so that
+# advice pointed at the one action that provably cannot work, at the moment the
+# operator is already blocked. The remaining causes are the ones named here.
 CHECKS_UNREADABLE = (
     "The rollup could not be read: `{why}`. An unreadable rollup is not a green "
-    "one — check that the reviewer credential carries `checks: read` on this "
-    "repo."
+    "one. On a credential that cannot read check runs the loop already fell "
+    "back to the Actions API, so reaching this point means that read failed "
+    "too — check the credential's `Actions: Read`, or whether the listing was "
+    "truncated (more contexts than the page bound)."
 )
 
 # The operator page for a native verdict post that keeps failing. Loud on
@@ -2438,10 +2462,24 @@ class ReviewWatcher:
         rollup = self.github.check_rollup(pr.owner, pr.repo, judged)
 
         if rollup.state == CHECKS_GREEN:
-            log.debug(
+            # `info`, not `debug`: this is the line an operator reads to find
+            # out WHICH read path called the head green, and on the deployment
+            # that needs the answer the fallback is every read.
+            log.info(
                 "%s round %d: CI rollup at %s is %s — approving as usual",
                 pr.slug, round_, judged[:8], rollup.summary,
             )
+            if rollup.via_actions_fallback:
+                # The one state where the marker had nowhere PR-visible to go.
+                # Every other path that surfaces `summary` (the hold activity
+                # comment, the degraded-verdict lead) is reachable only from
+                # PENDING or UNKNOWN, so "approved on green" -- the claim an
+                # operator acts on -- was the single verdict that did not say
+                # it came from the narrower read.
+                return ChecksGate(
+                    lead=CHECKS_FALLBACK_LEAD.format(sha=judged[:8]),
+                    state=CHECKS_GREEN,
+                )
             return ChecksGate()
 
         if rollup.state == CHECKS_RED:

alissa_tools_github_revloop-0.20.0/src/main/alissa/tools/github/revloop/version

@@ -0,0 +1 @@
+0.20.0

{alissa_tools_github_revloop-0.19.0 → alissa_tools_github_revloop-0.20.0/src/main/alissa_tools_github_revloop.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: alissa-tools-github-revloop
-Version: 0.19.0
+Version: 0.20.0
 Summary: ALISSA-TOOLS-GITHUB-REVLOOP
 Home-page: https://alissa.app
 Author: Fahera

alissa_tools_github_revloop-0.19.0/src/main/alissa/tools/github/revloop/version

@@ -1 +0,0 @@
-0.19.0