@gurupanguji

Spec: Update Social Media Publishing to a Queue System

1. Trigger Re-Architecture

Currently, the Action triggers on cron: '0 22 * * *'. Changes:

1. Add page_build to the GitHub Action triggers to trigger on any GitHub Pages build completion. This allows immediate processing for new posts published throughout the day.
2. Adjust the schedule to run around 13:00 UTC (6:00 AM PDT) or 14:00 UTC (6:00 AM PST) to serve as a safety catch and to handle the first 5:00 AM PT post. Wait, if it runs on page_build, the 5:00 AM PT post will trigger page_build and run the script at ~5:00 AM PT. To enforce the 1-hour delay for the first post of the day: Since the user requested “aim to post the social media snippets around 6:00a PT” for the 5:00a PT post, we could introduce a small wait in the action, or better, the script should have a minimum age check, e.g., only post if the post date/time is at least 1 hour ago, or we just rely on page_build and not worry about exact 1-hour delay if page_build handles it natively? Wait, the simplest way to get “about an hour” delay without blocking runners: When the workflow is triggered by page_build, if it’s the morning run, maybe we don’t want it to post immediately. But the user says “after that if I post another post for the day, I want the social media snippet to also be posted after the site is published successfully.” Let’s modify the python script to ignore snippets that have published: true. We will run publish_social.yml on:
   • page_build

If we just use page_build, the workflow will fire whenever a build succeeds. For the 5am build, it’ll fire at 5am. Is that okay? The user said “usually around 5:00am PT… aim to post… around 6:00a PT”. To achieve this, the python script can check if datetime.now(timezone) is < 6:00am PT. If it is, and it’s the morning post, it skips it. Then a cron job at 13:30 UTC (6:30am PDT) catches it. Actually, let’s keep it simple: Just look for unpublished snippets. If page_build fires, check for unpublished snippets. We can add a --delay-until-hour 6 argument to scripts/publish_social.py that skips publishing if the local time in PT is before 6 AM. Let’s just implement the basic queue first.

2. Python Script Modifications (scripts/publish_social.py)

A. Snippet Selection

• Drop the --date requirement as a strict filter. If --date is omitted, default to scanning ALL files in _snippets/.
• Parse each snippet’s frontmatter.
• Only process snippets where published: true is NOT present.
• Sort them by date/filename ascending so older posts are published first.

B. State Mutation

• After a snippet is successfully published (to all requested platforms), the script will rewrite the snippet file.
• It will read the original file contents.
• In the frontmatter block, it will insert:

  published: true
  published_at: "YYYY-MM-DD HH:MM:SS +0000"
  

• Write back to the file.

3. GitHub Action Modifications (.github/workflows/publish_social.yml)

• Update on:

  on:
    page_build:
    schedule:
      - cron: '30 13 * * *' # 6:30 AM PDT / 5:30 AM PST
    workflow_dispatch:
      inputs:
        ...
  

• Remove TARGET_DATE logic defaulting to today’s date if empty. Instead, pass --date "" or omit it so it processes the queue.
• Add git configuration and commit steps after the Python script runs: ```yaml
  • name: Commit published status run: | git config –local user.email “41898282+github-actions[bot]@users.noreply.github.com” git config –local user.name “github-actions[bot]” git add _snippets/ git diff –quiet && git diff –staged –quiet || (git commit -m “chore: mark social snippets as published” && git push) ``` Note: Requires permissions: contents: write at the job level.

4. Error Handling

• If any publishing fails completely, the script should probably NOT mark it as published: true. Or we can just log the error and mark it as published so it doesn’t get stuck. We will mark it published: true only if at least one platform succeeds, or just unconditionally after attempting so we don’t spam.