chore(ci): skip cron workflows gracefully when secrets are unset#23
Open
salishforge wants to merge 1 commit into
Open
chore(ci): skip cron workflows gracefully when secrets are unset#23salishforge wants to merge 1 commit into
salishforge wants to merge 1 commit into
Conversation
Both scheduled workflows (recompute-stale hourly, evaluate-alerts every
6h) have been failing 100% of runs (30/30 each, weeks of red) because
STONETRADE_BASE_URL and STONETRADE_CRON_TOKEN aren't configured as repo
secrets yet — the app isn't deployed where GitHub-hosted runners can
reach it. The original guard correctly exit 1'd, which is right once
production exists but produces ~30 failure notifications per day in the
pre-deploy window.
This PR keeps the guard but exits 0 with a ::warning:: annotation
instead. Net result:
- Run conclusion: success (Actions tab stops being a wall of red)
- Yellow warning annotation visible on the run list and at the top of
the job — same diagnostic message, just non-fatal
- Zero behaviour change once the secrets land: the curl call below
the guard executes exactly as before
Companion comments in both files explain the design so the next person
to touch them understands this is deliberate, not a missed exit code.
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Both scheduled workflows have been failing 100% of runs (30/30 each, weeks of red on the Actions tab) because
STONETRADE_BASE_URLandSTONETRADE_CRON_TOKENaren't configured as repo secrets yet — the app isn't deployed anywhere GitHub-hosted runners can reach. The originalexit 1guard is correct once production exists, but produces ~30 failure notifications per day in the meantime.This PR keeps the guard but exits
0with a::warning::annotation instead. Affects only the missing-secrets branch:Net result
curlcall below the guard executes exactly as beforeWhy this is the right shape
Companion code comments in both files explain the design so the next person to touch them doesn't read it as a missed exit code and "fix" it back to
exit 1. The contract is: skip-on-missing-secrets is intentional pre-deploy; once secrets are configured this becomes the live path.Once production is up
Repo → Settings → Secrets and variables → Actions → add:
STONETRADE_BASE_URL= deployed app URL (must not be localhost; GH runners can't reach private hosts)STONETRADE_CRON_TOKEN= strong random string that matches the server'sCRON_TOKENenv var (openssl rand -hex 32)At that point the warning annotations disappear and the crons start hitting the live
/api/admin/recompute-staleand/api/admin/alerts/evaluateendpoints.Test plan
recompute-stalerun (top of next hour at :17) reportssuccesswith a yellow warning annotation rather than redGenerated by Claude Code