✨ Rules Sync - Update JSON without full site redeploy

[Aibono1225]

Requested by: @Aibono1225 via YakShaver.ai 🦬
cc: @Marxoz, @Aibono1225, @PothieuG, @Freego1783

Hi Team!

  🟥  Watch the video (2 min 2 sec)

  Url from screen share: https://ssw.com.au/people/gert-marx/

Pain

On the SSW People Profile page, the "Latest Rules" list is powered by a pre-generated JSON file (people-latest-rules.json) that contains the five most recently modified rules per person. This approach improves performance, but currently requires a scheduled workflow that rebuilds and redeploys the entire Rules website daily to keep the JSON up to date. We need a more efficient solution to update or regenerate this JSON without triggering a full site rebuild and redeploy.

Acceptance Criteria

1. The people-latest-rules.json file is kept up to date without requiring a full website rebuild or redeploy.
2. The solution continues to return the top five last-modified rules per person as currently defined.
3. The performance of the SSW People Profile page is not degraded compared to the current implementation.
4. The update mechanism is automated and does not require manual intervention.
5. The solution is documented, including how and when the JSON is updated.

Screenshot

Figure: People profile latest rules sourced from static JSON showing only top five modified items

[github-actions]

🔍 Research & Analysis

What the Current System Does

people-latest-rules.json is generated at build time by scripts/generate-people-latest-rules.js. It:

1. Fetches active staff from Dynamics CRM
2. Clones and scans the SSW.Rules.Content git log (git log -n 100000) to find which rules each GitHub user authored or co-authored
3. Writes the top 5 most recently modified rules per person to public/people-latest-rules.json
4. The file is baked into the Docker image and served as a static asset from public/

The file is gitignored (public/people-latest-rules.json is in .gitignore), so it's only present when built.

A scheduled daily workflow (scheduled-production-deploy.yml) triggers a full rebuild + redeploy at 1:00 AM EST to keep it fresh.

---

Why This Is Non-Trivial

The core challenge is that the generation logic depends on git log access to the Content repo — something not available at runtime inside a running container. This makes a simple "generate on demand via API" approach difficult without significant changes.

---

Relevant Files

File	Role
scripts/generate-people-latest-rules.js	Build-time generator — git log scanning, CRM fetch, title lookup
public/people-latest-rules.json	Output JSON (gitignored, built into Docker image)
.github/workflows/build-artifacts.yml (lines 258–287)	Where the JSON is generated during builds
.github/workflows/scheduled-production-deploy.yml	Daily trigger that rebuilds just to refresh this JSON
app/api/revalidate/route.ts	Existing TinaCMS webhook handler with revalidatePath/revalidateTag
app/api/revalidate-tag/route.ts	Existing generic tag revalidation endpoint

---

Possible Approaches

Option A: Dedicated lightweight GitHub Actions workflow + Azure Blob Storage (Recommended)

1. Create a new update-people-latest-rules.yml workflow on a schedule (e.g., daily or on Content repo push via repository_dispatch)
2. The workflow runs the generation script (checks out both repos, calls pnpm generate:people-latest-rules)
3. Uploads the resulting JSON to Azure Blob Storage (already used for images in this project)
4. Create a new Next.js API route /api/people-latest-rules that proxies/caches the blob storage response using unstable_cache with a revalidation tag
5. SSW.People fetches from the API route instead of the static file

Pros: No full rebuild needed; decoupled; can run independently
Cons: Requires Azure Blob Storage setup + a new API route; SSW.People URL would change

---

Option B: Separate workflow that commits the JSON to the repo

1. Remove people-latest-rules.json from .gitignore or put it in a different path (e.g., content/ or a dedicated branch)
2. A lightweight workflow generates and commits the JSON
3. The content update triggers only a TinaCMS revalidation, not a full deploy

Pros: Low infrastructure changes
Cons: Git history noise from auto-commits; may still trigger deploys depending on branch rules

---

Option C: Switch to TinaCMS GraphQL API at runtime (partial fit)

Replace git log scanning with TinaCMS's latestRulesQuery + per-author filtering. TinaCMS already has lastUpdated sort.

Pros: Works at runtime, supports ISR/cache invalidation
Cons: TinaCMS doesn't natively track per-author rule modifications — the git log approach is more accurate for authorship attribution

---

Option D: repository_dispatch webhook from SSW.Rules.Content

When a rule is updated in the Content repo, it fires a repository_dispatch event to SSW.Rules that triggers only the JSON generation + container update (e.g., via a deployment slot swap or API call).

Pros: Near-real-time updates; targeted
Cons: Requires Content repo webhook setup; complex orchestration

---

Open Questions for the Team

1. Where is people-latest-rules.json consumed? Is it fetched directly by ssw.com.au/people/ as a static file, or is it already going through a Next.js API route? (This affects whether the URL can change.)
2. Is Azure Blob Storage already configured for this site? (It appears to be used for uploaded images based on the blob URLs in the issue.)
3. How frequently do rules actually change? A daily refresh schedule may be fine, in which case a lightweight scheduled workflow (Option A) is the cleanest path.
4. What is the acceptable latency for the data to be stale? Hours? Days?
5. Is the Content repo (SSW.Rules.Content) on GitHub? This determines whether repository_dispatch (Option D) is feasible.

---

Confidence: Low (~35%)

This is a well-scoped feature request but requires meaningful architectural decisions: choosing a storage mechanism, potentially changing the URL consumed by SSW.People, and coordinating between two repos. The right approach depends on infrastructure constraints (Azure Blob, App Service plan) and team preferences that go beyond what's visible in this repo alone. Recommending Option A as the most pragmatic path, but this needs team input before implementation.

---

🤖 Research by GitHub Copilot

Generated by Issue Triage for issue #2513

[Aibono1225]

The daily deployment to production also keeps these JSON files up to date (not just people-latest-rules.json that I mentioned in the video):

• category-uri-title-map.json
• orphaned_rules.json
• redirects.json

We should also keep them in mind when working on this issue.