This is a Next.js + TinaCMS website pulling data from:
- Node.js (version defined in .nvmrc) – recommended to use nvm
- corepack (run corepack enable to manage correct pnpm version)
- pnpm package manager
- python
-
Clone this repo
-
Clone SSW.Rules.Content
-
Place both repos in the same parent directory e.g.
📁 SSW-dev/
├── 📁 SSW.Rules.Content/
└── 📁 SSW.Rules/ <--- This repo
-
Create a
.envfile based off.env.examplein the root of this repo - get the values from Keeper (SSW.Rules Environment Variables) -
Run
pnpm installto install packages -
Install
pyyamlpython package:py -3 -m pip install pyyaml -
Run
pnpm prepare:contentto generate required mapping JSON files (they are gitignored) -
Run
pnpm devto start the development server
To test changes to MDX rules:
-
Go to your branch in SSW.Rules.Content
-
Modify the rule MDX as needed
-
If there are any changes to categories, re-run
pnpm prepare:content -
Run
pnpm devin this project to start SSW.Rules locally -
Navigate to http://localhost:3000/rules/ to see your changes
Note:
pnpm devdoes not track changes in SSW.Rules.Content, therefore, you will need to re-run the command after you make changes
- Always create a new branch for your PBIs
- Always delete your branch once your PR has been merged
- To create a new content branch (in
SSW.Rules.Content), follow the setup steps in the Wiki
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 made to SSW.Rules are deployed as follows:
- main deploys to staging: https://ssw-rules-tina-staging-c5bwbjc4a8d2g8gm.australiaeast-01.azurewebsites.net/rules
- To deploy to production:
- Create a
release/xxbranch from the currentmaincommit you want to ship - Manually run the production deployment workflow in GitHub Actions
- production: https://www.ssw.com.au/rules
- Create a
-
build-rule-category-map.py
Generates two JSON files:rule-to-categories.json(maps rules to categories)category-uri-title-map.json(maps category URIs to titles)orphaned_rules.json(maps category URIs to titles)
Reads rule data from theSSW.Rules.Contentrepo and runs during the build process (via GitHub Actions) or manually fromscripts/tina-migration.
-
prepare-content.js
A Node.js script that runsbuild-rule-category-map.pyand moves the JSON files to the correct location for use by the website.
Uses theLOCAL_CONTENT_RELATIVE_PATHenvironment variable to locate the content repo.
-
build-rule-category-map.py
Similar logic to the version in PoC. It processes thecategories/folder and.mdxfiles to create the same JSON maps. -
convert-rule-md-to-mdx.py
Converts.mdrule files to MDX format compatible with TinaCMS.
Replaces custom markdown patterns (e.g.,Figure,good/bad/okboxes) with structured MDX components like<asideEmbed>and escapes special characters for valid formatting. -
modify-sub-categories-frontmatter.py
Updates frontmatter in sub-category files (excludingindex.md) to ensure consistency. -
modify-top-categories-frontmatter.py
Targetsindex.mdfiles in sub-category folders and updates frontmatter to match the expected format. -
modify-main-category-frontmatter
Updatesindex.mdfile at the root of the categories 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
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.
The Bookmark feature uses the SSW.Rules.Functions API.
Local debugging setup
- Clone the
SSW.Rules.Functionsrepository. - In the repo root, create a
local.settings.jsonfile and copy the values from Keeper (environment variables for the Functions app). - Start the Functions app in dev mode.
Local endpoint
-
By default, the API is available at:
http://localhost:7248. -
Bookmark data is persisted to the staging database.
-
Install nodejs version specified in
.nvmrc(Ideally usenvmto use the right version) -
Ensure corepack is enabled -
corepack enable(this allows auto-install of the correctyarnversion)
-
Clone the repo from https://github.com/SSWConsulting/SSW.Rules
-
Run
yarn installto install packages -
Create environment files
.env.developmentbased off.env.template- get the values from Keeper (SSW.Rules Environment Variables) -
For GitHub App authentication, set the following environment variables:
GH_APP_ID: Your GitHub App IDGH_APP_PRIVATE_KEY: Your GitHub App private key (PEM format, can be base64 encoded)GITHUB_APP_INSTALLATION_ID: (Optional) The installation ID. If not provided, the first installation will be used.
See GitHub App authentication documentation for more details.
