Publish episodes to ATProto every 30 minutes instead of daily#24
Publish episodes to ATProto every 30 minutes instead of daily#24argyleink wants to merge 1 commit into
Conversation
The publish workflow previously ran only after the daily site rebuild (workflow_run on Rebuild Astro Site), so a new episode could wait up to 24 hours before its standard.site document was created. The publish script reads the RSS feed directly and is idempotent, so it never needed the rebuild — give it its own 30-minute schedule and drop the coupling.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe publish-episodes GitHub Actions workflow is modified to trigger on a 30-minute cron schedule and manual dispatch instead of after the Rebuild Astro Site workflow completes. The job-level conditional gating the check job on the prior workflow's success is removed. ChangesWorkflow Trigger Update
Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/publish-episodes.yml (1)
15-17: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low valueConsider a concurrency guard for overlapping runs.
With no
workflow_rungating and a 30-minute cron, overlapping executions are possible if a run runs long (e.g., pnpm install slowness or ATProto API hiccups). The publish script's list-then-publish sequence (fetch existing paths, then create records) is not atomic, so two concurrent runs could both miss each other's in-flight writes and attempt duplicate publishes — the script already tolerates "already exists" errors gracefully, so this is low-risk, but adding aconcurrencygroup would avoid wasted runner time and redundant API calls.♻️ Optional: add concurrency group
on: schedule: - cron: "*/30 * * * *" + +concurrency: + group: publish-episodes + cancel-in-progress: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/publish-episodes.yml around lines 15 - 17, Add a concurrency guard to the publish-episodes workflow so overlapping cron runs cannot execute at the same time. Update the workflow definition in publish-episodes.yml to use a concurrency group for this job/workflow, since the existing list-then-publish flow in the publish script is not atomic and can cause duplicate API work when runs overlap. Keep the existing "already exists" tolerance, and use a stable identifier tied to the workflow name so only one run proceeds at once.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/publish-episodes.yml:
- Around line 15-17: Add a concurrency guard to the publish-episodes workflow so
overlapping cron runs cannot execute at the same time. Update the workflow
definition in publish-episodes.yml to use a concurrency group for this
job/workflow, since the existing list-then-publish flow in the publish script is
not atomic and can cause duplicate API work when runs overlap. Keep the existing
"already exists" tolerance, and use a stable identifier tied to the workflow
name so only one run proceeds at once.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5733e8ba-fa95-4b42-ae4f-bdd2a836bc13
📒 Files selected for processing (1)
.github/workflows/publish-episodes.yml
1 participant
Why
New episodes were only published to ATProto once a day:
publish-episodes.ymlwas chained to the daily 8:00 UTC site rebuild viaworkflow_run, so an episode could sit up to ~24h before itssite.standard.documentrecord was created (e.g., the June 19 episode dropped at 19:08 UTC and wasn't published until the next morning's run).What
scheduletrigger (every 30 minutes) and drop theworkflow_runcoupling to the rebuild. The publish script reads the RSS feed directly and dedupes against existing document records, so it never depended on the rebuild — polling it frequently is safe and idempotent.ifcondition that gated on the rebuild's conclusion.Worst-case latency drops from ~24h to ~30 min (plus GitHub's scheduling jitter). A no-op run takes ~30s of Actions time.
Alternatives considered
rel="hub"link, so there's no hub to subscribe to.repository_dispatch— would be true zero-latency if Flightcast offers one; can be layered on top of this later without conflict.The daily
rebuild.ymlis untouched — it still handles site content freshness.Summary by CodeRabbit