Skip to content

chore(ci): skip cron workflows gracefully when secrets are unset#23

Open
salishforge wants to merge 1 commit into
masterfrom
chore/silence-cron-until-deployed
Open

chore(ci): skip cron workflows gracefully when secrets are unset#23
salishforge wants to merge 1 commit into
masterfrom
chore/silence-cron-until-deployed

Conversation

@salishforge

Copy link
Copy Markdown
Owner

Summary

Both scheduled workflows have been failing 100% of runs (30/30 each, weeks of red on the Actions tab) because STONETRADE_BASE_URL and STONETRADE_CRON_TOKEN aren't configured as repo secrets yet — the app isn't deployed anywhere GitHub-hosted runners can reach. The original exit 1 guard is correct once production exists, but produces ~30 failure notifications per day in the meantime.

This PR keeps the guard but exits 0 with a ::warning:: annotation instead. Affects only the missing-secrets branch:

-  echo "STONETRADE_BASE_URL and STONETRADE_CRON_TOKEN must be set as repo secrets"
-  exit 1
+  echo "::warning::Skipping recompute-stale — STONETRADE_BASE_URL and/or STONETRADE_CRON_TOKEN repo secret not set. Configure both once the app is deployed."
+  exit 0

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 each job — same diagnostic message as before, just non-fatal
  • Zero behaviour change once the secrets land — the curl call below the guard executes exactly as before

Why 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's CRON_TOKEN env var (openssl rand -hex 32)

At that point the warning annotations disappear and the crons start hitting the live /api/admin/recompute-stale and /api/admin/alerts/evaluate endpoints.

Test plan

  • Diff reviewed — only the missing-secrets branches changed
  • After merge: confirm the next scheduled recompute-stale run (top of next hour at :17) reports success with a yellow warning annotation rather than red
  • Once secrets are eventually set: confirm the curl call executes (run conclusion stays success, no warning emitted)

Generated by Claude Code

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.
@supabase

supabase Bot commented Jun 18, 2026

Copy link
Copy Markdown

This pull request has been ignored for the connected project amxgqxjqqofqitjxfytq because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.


Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants