GitHub - SSWConsulting/SSW.Rules: Generator for ssw.com.au/rules (original) (raw)

Gitmoji Scheduled CodeAuditor test

This is a Next.js + TinaCMS website pulling data from:

Architecture Diagram

architecture diagram

Getting Started

Required Tools

F5 experience

  1. Clone this repo
  2. Clone SSW.Rules.Content
  3. Place both repos in the same parent directory e.g.
📁 SSW-dev/
├── 📁 SSW.Rules.Content/
└── 📁 SSW.Rules/ <--- This repo
  1. Create a .env file based off .env.example in the root of this repo - get the values from Keeper (SSW.Rules Environment Variables)
  2. Run pnpm install to install packages
  3. Install pyyaml python package: py -3 -m pip install pyyaml
  4. Run pnpm prepare:content to generate required mapping JSON files (they are gitignored)
  5. Run pnpm dev to start the development server

Syncing and Updating Content

To test changes to MDX rules:

  1. Go to your branch in SSW.Rules.Content
  2. Modify the rule MDX as needed
  3. If there are any changes to categories, re-run pnpm prepare:content
  4. Run pnpm dev in this project to start SSW.Rules locally
  5. Navigate to http://localhost:3000/rules/ to see your changes

Note: pnpm dev does not track changes in SSW.Rules.Content, therefore, you will need to re-run the command after you make changes

Branches

Builds & Deployment

Content Changes (SSW.Rules.Content)

Changes made in SSW.Rules.Content (e.g. rule MDX, categories, images) will go live after the PR is merged.

🎥 Watch the video: TinaCMS for GitHub - The SSW Rules Migration | Jake Bayliss | SSW Consulting

Code Changes (SSW.Rules)

Code changes made to SSW.Rules are deployed as follows:

PR Preview Deploy

To deploy a PR preview, add a comment to the PR: /deploy. This creates/updates a preview deployment (slot pr-<number>) and posts a comment with the preview URL.

Using a custom tina-lock.json in a PR preview

The build process checks whether a branch with the same name as the PR branch exists in SSW.Rules.Content. If found, that branch is used to source content (including tina-lock.json); otherwise it falls back to main.

This means if your PR requires a new tina-lock.json (e.g. you added or changed a TinaCMS collection), you can test it in the PR preview without touching main in the content repo:

  1. Create a branch in SSWConsulting/SSW.Rules.Content with the exact same name as your PR branch.
  2. Push the updated tina-lock.json (and any other content changes) to that branch.
  3. Comment /deploy on the PR - the preview build will automatically pick up the matching content branch.

Python Scripts

In this Repository (Website)

In the Content Repository

📁 Public Content Folder

All rule content (including .mdx files and images) live into the public/ folder.

🎥 The 3 options for storing markdown in GitHub for TinaCMS

public/
└── uploads/
    └── rules/
        ├── rule-a/
        │   ├── rule.mdx
        │   └── img.png
        └── rule-b/
            ├── rule.mdx
            └── img.png

📝 Adding Editorial Workflow

We've integrated TinaCMS with an editorial workflow to support content editing in a more structured way. If you're unfamiliar with how editorial workflows work in Tina, please refer to the official documentation:

👉 TinaCMS Editorial Workflow Documentation

This workflow allows for content changes to be reviewed before being published, improving collaboration and content quality.

🔖 Bookmarks (via SSW.Rules.Functions)

The Bookmark feature uses the SSW.Rules.Functions API.

Local debugging setup

  1. Clone the SSW.Rules.Functions repository.
  2. In the repo root, create a local.settings.json file and copy the values from Keeper (environment variables for the Functions app).
  3. Start the Functions app in dev mode.

Local endpoint

Getting ready for development