Bound each gh attempt at 30s, so a failing call ends as soon as before

.github/workflows/ci.yml

@@ -89,7 +89,7 @@ jobs:
     # for the check and again for its cleanup, so an API outage ends in a failed
     # step with its message rather than a job cancelled at the cap. The healthy
     # path takes seconds.
-    timeout-minutes: 25
+    timeout-minutes: 20
     steps:
       - uses: actions/checkout@v7.0.1
 

README.md

@@ -362,7 +362,7 @@ Any host that can reach `api.github.com` will do, and more than one is better.
 Install a release, which puts `github-cron-trigger` on PATH:
 
 ```sh
-pip install "github-cron-trigger @ git+https://github.com/curlewlabs-com/github-cron-trigger@v0.2.3"
+pip install "github-cron-trigger @ git+https://github.com/curlewlabs-com/github-cron-trigger@v0.2.4"
 ```
 
 Or check out a release tag and run it as `PYTHONPATH=src python3 -m

pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "flit_core.buildapi"
 
 [project]
 name = "github-cron-trigger"
-version = "0.2.3"
+version = "0.2.4"
 description = "Run each scheduled slot of a GitHub Actions workflow on time and exactly once, with GitHub's schedule as the backstop."
 readme = "README.md"
 license = "MIT"

src/github_cron_trigger/github.py

@@ -13,7 +13,13 @@
 
 # Bound on every `gh` call, so a stalled socket cannot hold a workflow step or an
 # unattended clock tick open until an outer timeout kills it without a report.
-GH_TIMEOUT_SECONDS = 60
+# GitHub ends any request that takes it more than 10 seconds to process, and
+# these calls are single requests or a page or two, so a healthy call finishes
+# well inside this. It is spent once per attempt, which makes it the larger part
+# of how long a failing call can take; a caller sizing a job timeout around a
+# call counts every attempt RETRY_DELAYS_SECONDS and RATE_LIMIT_DELAY_SECONDS
+# allow.
+GH_TIMEOUT_SECONDS = 30
 
 # Waits between attempts on a busy or unreachable API, one attempt per entry
 # plus a final one. Most such failures are a single lost answer that the next